Вот это — 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 А вообще мне кажется, что и исходный, и учлучшенный варианты одинаково хороши (ну, или для критиков — одинаково плохи). Я бы пожалел тратить время на такую переделку — если это единственная переделка и если она не вызвана внешней причиной вроде руководства по стилю программирования, принятому в проекте.
Хороший пример — метапрограммирование в C++. Появилось оно ещё в C++98 (причём оно в язык было не добавлено, а открыто… во время стандартизации этому уже внимание чуть-чуть уделили), однако «простые смертные» могут им пользоваться только начиная с C++17
Ну, не знаю… Я вот себя не считаю «небожителем», и с даже специалистом по C++, но вот template'ы и использовал, и свои писал ещё задолго до 2017 года.
Скорее всего тут дело в том, что это «метапрограммирование» в C++98 имело своего предшественника ещё в C — директиву препроцессора #define с параметрами. Которую мне тоже пришлось в свое время освоить, потому как использовалась она очень широко. Ну, а с template уже хотя бы некоторые вещи можно было делать по аналогии. Но некоторые другие (типа классов-функторов для STL) — таки да, пришлось осваивать.
Ну, а ещё эта аналогия и приобретенные ранее привычки очень помогали искать ошибки, которых тогда было в количестве — ибо в старых стандартах дозволялись многие вещи, которые потом, после разворачивания шалона, не компилировались с малопонятными ошибками.
По пунктам:
1. Вы игнорируете экономическую сторону вопроса обеспечения безопасности. А в оригинальном комментарии она была краеугольным камнем всех рассуждений.
2. Блокировка тут именно что не веерная, а совершенно прицельная, но — ограниченная техническими возможностями. Кстати, если бы шифрование содержимого тоннеля было бы идеальным (SNI все-таки — это компромис), то избыточная блокировка была бы неустранима вообще принципиально. Ну, а в реальности этого примера она ограничена экономическими соображениями, от чего положение ничуть не лучше.
Допустимость или недопустимость блокировок вообще — это вопрос субъективных ценностей, а такие вопросы я вообще предпочитаю не обсуждать ввиду очевидной непродуктивности обсуждения.
Угроза удаленного выполнения нежелательных программ через принимаемую браузером информацию слабо связана с возможностью модификации трафика на пути от источника, потому что и сам источник нельзя считать доверенным (возможна угроза через оригинальное немодифицированное содержимое), а потому защищаться от нее надо всегда, и потому — совсем другими методами.
3. Может, и затруднено, но возможно. Монополисты имеют возможность получить свои, специально выделенные для них IP и их группы. И если это им будет сулить выгоду (и по рукам им за это никто не даст)- воспользуются этими воможностями, не сомневайтесь.
4.
А меня, как потребителя, нет.
Ну, если вас волнует, кто и как распределяет не ваши деньги, то, оставаясь в рамках идеологии оригинального поста, возразить нечего: все рассуждения в нем основаны на частных материальных интересах, а не на соотвествии какми-либо идеалам. Мне, вот например, в принципе не нравится реклама (любая), а схема возмещения затрат на создание и поддержку ресурсов интернета через рекламу кажется мне нездоровой, и я готов заплатить рыночную цену за то, что мне хочется получить. Но я считаю, что выбор той или иной схемы возмещения затрат — это, пока схема не противоречит закону, частное дело владельца ресурса, т.е. меня оно не касается.
Ну, и ещё раз напоминаю (по поводу «запрета чтения»), что действительно ценная информация должна быть надлежащим образом защищена.
С возможностью модификации контента ресурса третьей стороной, группа этого ресурса, внимание, внезапно может быть изменена.
Понижена она незаметно для пользователя быть не может (браузер предупреждает сообщением типа «вы собираетесь отправить данные через незащищенное соединение» и т.п.), ну а повышена — да пожалуйста.
Это если и поможет, то далеко не во всех случаях, т.к. трафик модифицируется прямо перед отдачей данных непосредственно пользователю
В любом случае оригинальный трафик ресурса будет виден и это поможет владельцу ресурса избежать ответственности. Ну, а клиенту защищаться от таких атак нужно все равно.
PS Похоже, у вас система ценностей не соответсвует той, на которую опирается оригинальный комментарий: с вашей позиции, которая изложена чуть выше, я понял, что неограниченные свобода, приватность и т.п. идеальные ценности являются для вас бесценными, а комментарий оперался на другой подход: не на идеалы, а на прагматичное следование каждым своим материальным интересам в рамках закона. Если так, то дальнейшую дискуссию вести смысла нет: ни к каким выводам, не вызывающим возражений у дискутирующий, она все равно не приведет. Так что, если желаете, можете ответить на мой комментарий, и на этом мы с вами дискуссию закончим.
Либо, как вариант — продолжим её вести в рамках сугубо прагматичной системы ценностей.
Я сожалею, что мне не ответил автор предыдущего комментария, который прочел и прокомментировал мой оригинальный комментарий.
Так что, прошу прощения, я вам буду отвечать максимально кратко, поскольку ваш ответ несколько выбивается, как мне покзалось, из контекста предыдущего обсуждения.
По первой группе ваших аргументов.
1. Персональные данные я еще в своем оригинальном комментарии однозначно отнес к третьей группе — требующих максимальных мер защиты. Более того, для тех владельцев ресурсов, которые не осознают важность персональных данных, многие государства приняли законы (про Евросоюз и РФ — знаю про такие законы точно), заставляющие владельцев осознать важность этих данных под угрозой наказания.
2. Блокировки я вообще тут не обсуждал — я рассматривал чисто экономические аспекты.
Однако даже тут далеко не всё однозначно: избыточная защита может вредить. В частности, на моем личном примере: мой провайдер интернета (весьма небольшой) фактически блокирует мне доступ к сайту worldometers.info — одному из лучших источников информации о пандемии COVID-19. И делает он это не со зла, а потому что ровно на тех же IP на серверах Cloudflare размещен сайт онлайн-казино (надеюсь, вы не возражаете что есть причины блокировать такого рода ресурсы), а оборудование провайдера не позволяет выделить из SNI, к какому именно сайту идет доступ. Если бы данные worldometers.info не шифровались (безопасность это не нарушает, т.к. данные — общедоступные, первая группа в моем оригинальном комментарии), то моему провайдеру было бы легче блокировать только то, что блокировать ему надо.
3. Т.к. нарушать сетевой нейтралитет в пользу крупных компаний-монополий (т.е. там, где эти нарушения наиболее опасны) можно не по именам сайтов, а, с тем же успехом, по их IP, то считаю ваш аргумент опровергнутым.
4. Меня как потребителя мало волнует, кто именно показывает мне рекламу. Да, владельцев сайтов это волнует — они теряют деньги, потому они собственно и используют TLS. Но альтернатива тут есть: законодательный запрет искажения трафика провайдером, предусматривающий существенные штрафы и возмещение убытков распространителю исходной информации.
А угрозой подмены лично для меня данных из общедоступных источников я пренебрегаю: нет у меня столько денег, чтобы кому-то на этом можно было заработать.
5. Критически важные данные для функцинирования IoT — это опять-таки третья группа, требующая максимальных мер защиты.
Вторая группа аргументов
1,2. Разбиение по группам предлагается по ресурсам, а не по пользователям. Так что непонятно, как это помогло бы реализвать описанные вами угрозы.
3. Во-первых, ценные данные должны защищаться достаточно надежными методами (см. опять про третью группу), в том числе — от несанкционированного доступа из недоверенной области ресурса. Технически в браузерах сейчас это реализуется в полной мере.
А во-вторых, тут как раз мог бы, совместно с законом о запрете модификации трафика, помочь пресловутый «закон Яровой» (люблю случаи, когда можно получить пользу от того, что считается вредным): суд может запросить зафиксированный по этому закону трафик у хостинг-провайдера и провайдеров промежуточных операторов и по этим данным установить источник искажения.
И внешний наблюдатель не сможет знать что летит в шифрованной трубе: телеграмм или личный блог с котиками — для внешнего наблюдателя это должно быть не видно.
Поясните, пожалуйста, в чем риски того, что внешний наблюдатель определит категорию информации, которую получает пользователь. То есть, почему это настолько существенно повысит вероятность получить несанкционированный доступ к информации той самой третьей категории — которая одна имеет достаточную ценность, чтобы её имело смысл защищать серьезными мерами — что оправдает тотальное применение этих серьезных мер по защите информации.
Я таких рисков не вижу. Но, может быть, я что-то упустил.
PS: интересно, в чем проблема обновлять свои сертификаты на load balancer’e в автоматическом режиме? А если компания не такая большая и LB отсутствует — тогда CloudFlare все может сделать сам, вместо админа...
Проблема — исключительно в дополнительных затратах на поддержание безопасности. Есть общий принцип выбора экономически обоснованного уровня безопасности: стоимость мер защиты не должна превышать возможный ущерб. А значительная часть информации в Интернете не имеет такой ценности, чтобы оправдать затраты даже на столь несложные меры по её защите. Для первой категория это однозначно так — там цена информации практически нулевая. Насчет второй, конечно, надо считать конкретно каждый случай, но что-то мне подсказывает, что для большинства случаев в этой категории вывод будет тот же: усиление защиты невыгодно.
Немного личного опыта. Однажды я реализовал некую подсистему в стиле «не больше 4х строк на метод». Код офигеть как понятен
Ну, не знаю, не знаю. Такой стиль написания, если смысл функции хоть чуть-чуть оказывается непонятен, вынуждает читающего беuать взад-вперед по по тексту программы не меньше, чем чем классический «фортрановский» спагетти-код с кучей GOTO.
И уж, во всяком случае, я бы предпочел вместо private функций, состоящие из вызова одного метода одного поля класса, вставлять в код сам вызов этого метода, чтобы избежать дополнительного уровня абстракции. Потому что даже если потребеутся поменять логику реализации, найти все все такие вызовы и переписать их можно обычным поиском-заменой в редакторе.
У меня есть подозрение, что здесь дядюшку Боба просто поняли неправильно.
В достаточно старых языках программирования (FORTRAN, PL/I и большинство их ровесников) было четкое, на уровне языка, разделение вызваемых модулей на функции — которые возвращают значение на основе переданных аргументов (возможно, производя на эти аргументы какие-то побочные эффекты), и процедуры — которые что-то делают с переданными им аргументами, но значения не возвращают, и сам смысл которых — как раз в том, что для функций называлось бы побочным эффектом.
И вот мне кажется, что автор «Чистого кода» использовал слово «функция» именно в этом контексте.
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 А вообще мне кажется, что и исходный, и учлучшенный варианты одинаково хороши (ну, или для критиков — одинаково плохи). Я бы пожалел тратить время на такую переделку — если это единственная переделка и если она не вызвана внешней причиной вроде руководства по стилю программирования, принятому в проекте.
Ну, не знаю… Я вот себя не считаю «небожителем», и с даже специалистом по C++, но вот template'ы и использовал, и свои писал ещё задолго до 2017 года.
Скорее всего тут дело в том, что это «метапрограммирование» в C++98 имело своего предшественника ещё в C — директиву препроцессора #define с параметрами. Которую мне тоже пришлось в свое время освоить, потому как использовалась она очень широко. Ну, а с template уже хотя бы некоторые вещи можно было делать по аналогии. Но некоторые другие (типа классов-функторов для STL) — таки да, пришлось осваивать.
Ну, а ещё эта аналогия и приобретенные ранее привычки очень помогали искать ошибки, которых тогда было в количестве — ибо в старых стандартах дозволялись многие вещи, которые потом, после разворачивания шалона, не компилировались с малопонятными ошибками.
1. Вы игнорируете экономическую сторону вопроса обеспечения безопасности. А в оригинальном комментарии она была краеугольным камнем всех рассуждений.
2. Блокировка тут именно что не веерная, а совершенно прицельная, но — ограниченная техническими возможностями. Кстати, если бы шифрование содержимого тоннеля было бы идеальным (SNI все-таки — это компромис), то избыточная блокировка была бы неустранима вообще принципиально. Ну, а в реальности этого примера она ограничена экономическими соображениями, от чего положение ничуть не лучше.
Допустимость или недопустимость блокировок вообще — это вопрос субъективных ценностей, а такие вопросы я вообще предпочитаю не обсуждать ввиду очевидной непродуктивности обсуждения.
Угроза удаленного выполнения нежелательных программ через принимаемую браузером информацию слабо связана с возможностью модификации трафика на пути от источника, потому что и сам источник нельзя считать доверенным (возможна угроза через оригинальное немодифицированное содержимое), а потому защищаться от нее надо всегда, и потому — совсем другими методами.
3. Может, и затруднено, но возможно. Монополисты имеют возможность получить свои, специально выделенные для них IP и их группы. И если это им будет сулить выгоду (и по рукам им за это никто не даст)- воспользуются этими воможностями, не сомневайтесь.
4.
Ну, если вас волнует, кто и как распределяет не ваши деньги, то, оставаясь в рамках идеологии оригинального поста, возразить нечего: все рассуждения в нем основаны на частных материальных интересах, а не на соотвествии какми-либо идеалам. Мне, вот например, в принципе не нравится реклама (любая), а схема возмещения затрат на создание и поддержку ресурсов интернета через рекламу кажется мне нездоровой, и я готов заплатить рыночную цену за то, что мне хочется получить. Но я считаю, что выбор той или иной схемы возмещения затрат — это, пока схема не противоречит закону, частное дело владельца ресурса, т.е. меня оно не касается.
Ну, и ещё раз напоминаю (по поводу «запрета чтения»), что действительно ценная информация должна быть надлежащим образом защищена.
Понижена она незаметно для пользователя быть не может (браузер предупреждает сообщением типа «вы собираетесь отправить данные через незащищенное соединение» и т.п.), ну а повышена — да пожалуйста.
В любом случае оригинальный трафик ресурса будет виден и это поможет владельцу ресурса избежать ответственности. Ну, а клиенту защищаться от таких атак нужно все равно.
PS Похоже, у вас система ценностей не соответсвует той, на которую опирается оригинальный комментарий: с вашей позиции, которая изложена чуть выше, я понял, что неограниченные свобода, приватность и т.п. идеальные ценности являются для вас бесценными, а комментарий оперался на другой подход: не на идеалы, а на прагматичное следование каждым своим материальным интересам в рамках закона. Если так, то дальнейшую дискуссию вести смысла нет: ни к каким выводам, не вызывающим возражений у дискутирующий, она все равно не приведет. Так что, если желаете, можете ответить на мой комментарий, и на этом мы с вами дискуссию закончим.
Либо, как вариант — продолжим её вести в рамках сугубо прагматичной системы ценностей.
Так что, прошу прощения, я вам буду отвечать максимально кратко, поскольку ваш ответ несколько выбивается, как мне покзалось, из контекста предыдущего обсуждения.
По первой группе ваших аргументов.
1. Персональные данные я еще в своем оригинальном комментарии однозначно отнес к третьей группе — требующих максимальных мер защиты. Более того, для тех владельцев ресурсов, которые не осознают важность персональных данных, многие государства приняли законы (про Евросоюз и РФ — знаю про такие законы точно), заставляющие владельцев осознать важность этих данных под угрозой наказания.
2. Блокировки я вообще тут не обсуждал — я рассматривал чисто экономические аспекты.
Однако даже тут далеко не всё однозначно: избыточная защита может вредить. В частности, на моем личном примере: мой провайдер интернета (весьма небольшой) фактически блокирует мне доступ к сайту worldometers.info — одному из лучших источников информации о пандемии COVID-19. И делает он это не со зла, а потому что ровно на тех же IP на серверах Cloudflare размещен сайт онлайн-казино (надеюсь, вы не возражаете что есть причины блокировать такого рода ресурсы), а оборудование провайдера не позволяет выделить из SNI, к какому именно сайту идет доступ. Если бы данные worldometers.info не шифровались (безопасность это не нарушает, т.к. данные — общедоступные, первая группа в моем оригинальном комментарии), то моему провайдеру было бы легче блокировать только то, что блокировать ему надо.
3. Т.к. нарушать сетевой нейтралитет в пользу крупных компаний-монополий (т.е. там, где эти нарушения наиболее опасны) можно не по именам сайтов, а, с тем же успехом, по их IP, то считаю ваш аргумент опровергнутым.
4. Меня как потребителя мало волнует, кто именно показывает мне рекламу. Да, владельцев сайтов это волнует — они теряют деньги, потому они собственно и используют TLS. Но альтернатива тут есть: законодательный запрет искажения трафика провайдером, предусматривающий существенные штрафы и возмещение убытков распространителю исходной информации.
А угрозой подмены лично для меня данных из общедоступных источников я пренебрегаю: нет у меня столько денег, чтобы кому-то на этом можно было заработать.
5. Критически важные данные для функцинирования IoT — это опять-таки третья группа, требующая максимальных мер защиты.
Вторая группа аргументов
1,2. Разбиение по группам предлагается по ресурсам, а не по пользователям. Так что непонятно, как это помогло бы реализвать описанные вами угрозы.
3. Во-первых, ценные данные должны защищаться достаточно надежными методами (см. опять про третью группу), в том числе — от несанкционированного доступа из недоверенной области ресурса. Технически в браузерах сейчас это реализуется в полной мере.
А во-вторых, тут как раз мог бы, совместно с законом о запрете модификации трафика, помочь пресловутый «закон Яровой» (люблю случаи, когда можно получить пользу от того, что считается вредным): суд может запросить зафиксированный по этому закону трафик у хостинг-провайдера и провайдеров промежуточных операторов и по этим данным установить источник искажения.
Поясните, пожалуйста, в чем риски того, что внешний наблюдатель определит категорию информации, которую получает пользователь. То есть, почему это настолько существенно повысит вероятность получить несанкционированный доступ к информации той самой третьей категории — которая одна имеет достаточную ценность, чтобы её имело смысл защищать серьезными мерами — что оправдает тотальное применение этих серьезных мер по защите информации.
Я таких рисков не вижу. Но, может быть, я что-то упустил.
Проблема — исключительно в дополнительных затратах на поддержание безопасности. Есть общий принцип выбора экономически обоснованного уровня безопасности: стоимость мер защиты не должна превышать возможный ущерб. А значительная часть информации в Интернете не имеет такой ценности, чтобы оправдать затраты даже на столь несложные меры по её защите. Для первой категория это однозначно так — там цена информации практически нулевая. Насчет второй, конечно, надо считать конкретно каждый случай, но что-то мне подсказывает, что для большинства случаев в этой категории вывод будет тот же: усиление защиты невыгодно.
Ну, не знаю, не знаю. Такой стиль написания, если смысл функции хоть чуть-чуть оказывается непонятен, вынуждает читающего беuать взад-вперед по по тексту программы не меньше, чем чем классический «фортрановский» спагетти-код с кучей GOTO.
И уж, во всяком случае, я бы предпочел вместо private функций, состоящие из вызова одного метода одного поля класса, вставлять в код сам вызов этого метода, чтобы избежать дополнительного уровня абстракции. Потому что даже если потребеутся поменять логику реализации, найти все все такие вызовы и переписать их можно обычным поиском-заменой в редакторе.
В достаточно старых языках программирования (FORTRAN, PL/I и большинство их ровесников) было четкое, на уровне языка, разделение вызваемых модулей на функции — которые возвращают значение на основе переданных аргументов (возможно, производя на эти аргументы какие-то побочные эффекты), и процедуры — которые что-то делают с переданными им аргументами, но значения не возвращают, и сам смысл которых — как раз в том, что для функций называлось бы побочным эффектом.
И вот мне кажется, что автор «Чистого кода» использовал слово «функция» именно в этом контексте.