Там была новость о том, что учёные только планируют объявить о своём достижении. А эта новость уже о том, что они наконец объявили о нём. Следующая новость будет о том, что у учёных всё идёт по плану, со ссылкой на предыдущие две новости, в качестве подтверждения.
Однако новые правила коснутся не всех. У Nvidia есть 20-летняя лицензия на разработку компонентов с Arm-архитектурой, а Apple стояла у истоков Arm. Кроме того, нововведения не затронут сотрудничество Arm с Broadcom.
На лицо создание не конкурентных условий. Антимонопольщики могут вмешаться. Я бы даже сказал, что они должны вмешаться.
В начале февраля 2021 года ФАС возбудила дело против оператора Tele2 за увеличение стоимости услуг связи для пользователей на 13% с 1 января 2021 года. Повышение цен на тарифы затронуло более 12 млн абонентов по всей стране.
В ноябре 2021 года ФАС оштрафовала Tele2 на 825,5 тыс. рублей
ФАС после этого пояснила, что Tele2 с 11 января 2022 года снизит необоснованно повышенные тарифы к уровню до повышения.
Так, и что мы тут имеем? Тарифы были завышены на протяжении целого года. Учитывая количество абонентов, даже если с каждого из них, за это время, был получен всего один лишний рубль, то выгода в 14,5 раз превышает сумму штрафа (12 миллионов против 825 тысяч). В принципе, дальше считать бессмысленно, но чисто для ориентировки, если изначально абонент тратил 100 рублей в месяц, то повышение на 13% даёт 156 дополнительных рублей в год с такого абонента. Тут я хотел смешно пошутить, но вдруг понял, что это уже сделал автор законов, по которым присуждают такие вот штрафы, а я наоборот, только испортил всю шутку, пытаясь объяснить её суть. З.Ы. Процитировал и разобрал ситуацию именно с Tele2, потому что с Мегафоном дело ещё не завершилось, и нет суммы штрафа. Впрочем, итог мне кажется немного предсказуемым.
Можно подумать, установка в свою систему приложений, которым ты не доверяешь, лучше чем установка сертификатов. В каком-то смысле, даже хуже.
Лучше поставить отдельную сборку Firefox (допустим Nightly, или вообще что-то своё собрать), добавить в него вот этот сертификат (у лисы своё хранилище, не на уровне ОС), и пользоваться этой сборкой только для сервисов Сбера. Таким образом, в системе не будет ни сомнительных сертификатов, ни сомнительного ПО.
Корреляция != причина. Если не выяснен механизм, каким именно образом упражнения снижают риск смерти (а об этом в статье ни слова), то можно говорить лишь о корреляции. Не стоит забывать, что среди людей, которые регулярно занимаются спортом, будет статистически больше людей, ведущих здоровый образ жизни.
Исследователи из университетов США, Бразилии, Чили и Испании в течение 30 лет изучали, как количество физических упражнений влияет на риск преждевременной смерти.
Авторы использовали данные из национального исследования США за период с 1988 по 2018 год.
Пока в Виллабаджо 30 лет собирали данные, студенты из Вилларибо загнали эти данные в Excel и поигрались со статистикой.
Мне кажется, они специально включили AirDrop, и разрешили принимать сообщения от всех, чтобы ловить потенциальных шутников на живца. Шутник ведь будет всем подряд слать свой «контент». Следовательно, экипаж сразу будет в курсе, и сможет предпринять меры.
Министерство иностранных дел РФ с 26 августа приостановило выдачу загранпаспортов, которые действуют 10 лет.
Одновременно с этим на портале Госуслуг недоступны разделы, где можно оформить любые паспорта, даже российский, а также регистрацию по месту жительства и приглашение на въезд в РФ.
Портал поясняет, что сервис МВД недоступен и предлагает подать заявление позже.
так как компания не выпускает уникальных и обязательных игр
Способность этих людей толкать буллшит просто поражает. Даже интересно бы было увидеть пример обязательной игры. Воображение рисует голодные игры или что-то подобное.
При первом взгляде на этот индекс становится ясно, что местами он совершенно неадекватен. JavaScript в два раза менее актуален чем Visual Basic. Delphi скоро обгонит Swift. SQL присутствует в индексе наравне с языками общего назначения. Какой-то Assembly language, оказывается, существует. Не иначе как кроссплатформенный ассемблер. Тем временем, на нижних этажах, Kotlin менее актуален чем Ada и Prolog, а снизу его подпирают Lisp и COBOL.
Свалили всё в кучу, посчитали какие-то формальные критерии, которые иногда коррелируют с востребованностью языка, а иногда нет. Не учтён важнейший фактор — сферы применения каждого языка. Без этого невозможно понять, какие языки действительно конкурируют между собой, и кто из них действительно является лидером в своей нише. Даже интересно, у этого индекса есть хоть какая-то полезность? Лично мне кажется, что нет, но может я что-то упускаю?
class Fahrenheit {
constructor(value, key) {
if (Fahrenheit.#key !== key) throw new Error("Using of raw constroctor is not allowed. Use fromCelsius method instead.");
this.#value = value;
}
static #key = new Object();
#value;
static fromCelsius(value) {
return new Fahrenheit(value * 9/5 + 32, Fahrenheit.#key);
}
}
А вообще, пример, конечно, притянут за уши. Обычно, приватные конструкторы нужны для реализации синглтонов. Но в JS можно реализовать синглтон и без этого.
По вкусу, можно добавить выбрасывание ошибки при повторном явном вызове конструктора, статический метод getInstance, ну и т.д.
На вскидку, сложно сказать, насколько реально нужен приватный конструктор в JS, но он уж точно не является приоритетом. Вот чего не хватает, так это модификатора protected. Уж если начали модификаторы доступа добавлять, не стоило останавливаться на private.
На самом деле, хорошая схема, но терминология слишком мудрёная. Зачем тут аж четыре языка и какие-то метасмыслы? Речь, по сути, о том, какие обстоятельства или аспекты планируется передать предложением. Вот так и стоило назвать.
От слова «комплементарный» тоже лучше избавиться. Почему не сказать просто «дополнительный»? Дополнительный аспект, дополнительное обстоятельство, дополнительный смысл. Не нужно никаких сложных слов, там где можно обойтись простыми.
Уверен, и прочую терминологию можно упростить. При этом, основная идея не пострадает, а наоборот станет только понятнее.
Назначение самих аспектов, лично я бы сформулировал несколько иначе. Может это и вкусовщина, но если давать классификацию, то признак для классификации должен быть единым. Лично я всегда понимал Progressive и Perfect как способы показать относительное положение событий во времени. Как правило, нам может быть важно, пересеклись ли события во времени (одновременность событий), и какое из них предшествовало другому (последовательность событий). В итоге, получается такая классификация:
Simple — Основной аспект. Просто факты. Что, когда, как часто происходило, происходит, будет происходить. Нет указания на отношения с другими событиями.
Progressive — указывает на одновременность нескольких событий, пересечение их во времени. Внезапно, пересечение во времени сложно показать без указания на то, что хотя бы одно из событий не было моментальным, т.к. редко что-то происходит абсолютно одновременно. Какое-то событие, как правило, начинается раньше, и длится некоторое время прежде чем пересечётся во времени с другим событием. Так же, стоит отметить, что текущий момент всегда происходит одновременно с разговором, поэтому для него тоже используется Progressive.
Perfect — указывает на последовательность событий, предшествование одного другому. Для этого одно из событий должно завершиться до начала другого, поэтому требуется совершенная форма.
Perfect Progressive — указывает на последовательность и в то же время, на пересечение событий во времени. Иногда нам важно, и то что события пересеклись во времени, и то что одно из них началось раньше. Раз уж нам важны такие нюансы, как правило, важно ещё и насколько раньше одно из событий началось, как долго оно продолжалось, поэтому, такая информация здесь указывается явно.
Самое главное, при такой классификации, даже не надо отдельно оговариваться что все аспекты, кроме Simple, являются составными, и требуют указания второго события или наличия контекста, ведь речь идёт об относительном положении событий во времени.
Главный вопрос — зачем? Обычно мы об этом не думаем, просто действуем по наитию. Нынешняя цивилизация как-то сама собой образовалась. Но если уж мы начинаем рассуждать о выходе на качественно новый уровень, наверное стоит задуматься о целях? Каких целей предлагается достичь? Размножение? Это не наша цель, а наших генов. Выживание? Это даже не цель, а средство, ну или, можно сказать, условие, временное выполнение которого необходимо, чтобы гены могли размножиться. А что касается людей, то своей цели у нас, как бы и нет. Есть только инстинкт, навязанный процессом естественного отбора генов. Нам словно сказали: «Плодитесь и размножайтесь» — и мы так и делаем, даже не задумываясь, нужно ли это нам самим. Уже вон, за пределы планеты планируем размножиться. И весь этот путь проделан в попытках достичь чужой цели, не своей.
Пока не будет найдена собственная цель, нет смысла говорить о каких-то там цивилизациях, какого-либо типа. Живая масса без собственной цели — это не цивилизация, поглоти она хоть энергию всей Вселенной. Цивилизация тем и отличается от всех остальных форм организации материи, что она создаётся разумными существами. Если существа не понимают, зачем они существуют, их сложно назвать разумными в полной мере. У людей пока только есть потенциал осознать себя, но они его ещё не реализовали. А до тех пор, мы даже не знаем, нужно ли нам увеличивать масштаб нашей «цивилизации». Не зная к чему хочешь придти, глупо выбирать путь. Это как искать ответ, не зная вопроса.
Автор сначала утверждает, что программировать не сложно, и тут же заявляет, что главная проблема — разочарование от неудач. Вижу здесь серьёзное противоречие. Чтобы разочарование было регулярным, неудачи тоже должны быть обычным делом. Откуда же берутся неудачи в таком количестве? Очевидно, они возникают из-за сложности. Чем сложнее задача, тем чаще человек терпит неудачу, и тем большее психологическое давление испытывает. С простой задачей такого бы не происходило.
Давайте проведём аналогию с играми, раз уж автор приводит пример с игрой из детства. Если подумать, игры здесь очень хорошо подходят в качестве модели. Думаю, любой человек с солидным игровым опытом, не раз сталкивался со сложными уровнями или миссиями в играх, для прохождения которых требовалось предпринимать десятки, а то и сотни попыток. Вспомните 3-й уровень в Battletoads, где нужно ездить на байке, миссию с вертолётиком в GTA Vice City или миссию с гонкой в первой Мафии. Признаюсь честно, иногда я бросал игры из-за таких миссий, например, я так и не прошёл первую Мафию.
Программирование напоминает именно такие игры. Посреди простых и умеренно сложных задач, периодически встречаются особенно сложные «миссии». Но ведь эта неравномерность объективно увеличивает общую сложность всей задачи, причём, вовсе не за счёт вклада в среднюю сложность, а гораздо сильнее. Легко обмануться, приняв среднюю сложность за общую, но чтобы достичь цели, надо пройти весь путь, а для этого вам должна быть по плечу не только средняя его сложность, но и пиковая. Следовательно, сложность всего пути не равна средней сложности всех его участков. Простое среднее — это лишь минимально возможная сложность, если считать что распределение сложности по участкам близко к равномерному. Неравномерность существенно влияет на общую сложность в сторону её увеличения, по сравнению со средней, и это не субъективное восприятие, а объективный факт.
Можно долго рассуждать о психологии, стойкости, упорстве, готовности терпеть неудачи, и т.д. Но глупо при этом отрицать, что всё это требуется, прежде всего, при решении объективно сложных задач. То что сложные задачи являются ещё и серьёзным психологическим испытанием, это лишь положительная обратная связь. Чем агрессивнее внешние условия, чем ближе режим работы к пределам возможностей, тем выше вероятность, что проявятся ещё и внутренние проблемы. В этом нет никакого откровения. Это просто очевидно.
Если у нас есть числа, больше числа, строки, символы, логические или неопределенные значения
Более полезно, когда у нас есть переменные
Не удержался
У нас было 2 массива строк, 75 больших чисел, 5 логических значений, пол-килобайта символов и гора объектов всех разновидностей и цветов, а ещё литерал строки, объектный литерал, WeakMap и половина переменных с неопределённым значением. Не то, чтобы это всё было нужно в нашем коде, но раз начал писать на JavaScript, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это undefined. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек отлаживающий ошибки, связанные с undefined в JS коде. И я знал, что довольно скоро мы в это окунёмся.
Может в английском «we have» и звучит нормально, в данном контексте, но по русски это звучит просто смешно. Статья, сама по себе, очень слабая, и местами даже вредная, но вам удалось её ухудшить.
Ещё и пропустили абзац про Multiple Frames and Windows. Это важное ограничение instanceof. Я было хотел поругать автора за то, что не упомянул это, но в английском оригинале про это написано, хотя и без детальных пояснений.
Instanceof полезен для проверки всего, что создано с помощью оператора new, включая строки, логические значения и числа.
А вот за это автору оригинала надо поставить двойку. Формально, оператор instanceof действительно сработает для примитива, если тот был создан с помощью new. Но говорить что он в этом случае полезен — это преступление. Напротив, это выстрел в ногу. В том участке кода, где вам может понадобится проверка, вы никогда не будете знать, как было создано значение, вы не можете знать, использовался ли оператор new или нет, следовательно, не можете на это полагаться. Вы потому и проверяете, что не знаете, что там. Поэтому, никогда нельзя проверять с помощью instanceof те типы, для которых есть отдельное значение у оператора typeof: string, number, boolean, bigint, symbol.
Там была новость о том, что учёные только планируют объявить о своём достижении. А эта новость уже о том, что они наконец объявили о нём.
Следующая новость будет о том, что у учёных всё идёт по плану, со ссылкой на предыдущие две новости, в качестве подтверждения.А в патенте не указано, должна ли на внутренней стороне, при нагревании, появляться надпись?
https://twitter.com/elonmusk/status/1589009644114284544
На лицо создание не конкурентных условий. Антимонопольщики могут вмешаться. Я бы даже сказал, что они должны вмешаться.
Так, и что мы тут имеем? Тарифы были завышены на протяжении целого года. Учитывая количество абонентов, даже если с каждого из них, за это время, был получен всего один лишний рубль, то выгода в 14,5 раз превышает сумму штрафа (12 миллионов против 825 тысяч). В принципе, дальше считать бессмысленно, но чисто для ориентировки, если изначально абонент тратил 100 рублей в месяц, то повышение на 13% даёт 156 дополнительных рублей в год с такого абонента. Тут я хотел смешно пошутить, но вдруг понял, что это уже сделал автор законов, по которым присуждают такие вот штрафы, а я наоборот, только испортил всю шутку, пытаясь объяснить её суть.
З.Ы. Процитировал и разобрал ситуацию именно с Tele2, потому что с Мегафоном дело ещё не завершилось, и нет суммы штрафа. Впрочем, итог мне кажется немного предсказуемым.
Если в компании даже на инфляцию зарплату не индексируют, то тут никакой менеджер по развитию не поможет. Текучка на такой работе будет всегда.
Лучше поставить отдельную сборку Firefox (допустим Nightly, или вообще что-то своё собрать), добавить в него вот этот сертификат (у лисы своё хранилище, не на уровне ОС), и пользоваться этой сборкой только для сервисов Сбера. Таким образом, в системе не будет ни сомнительных сертификатов, ни сомнительного ПО.
Пока в Виллабаджо 30 лет собирали данные, студенты из Вилларибо загнали эти данные в Excel и поигрались со статистикой.
Это если не учитывать инфляцию.
Способность этих людей толкать буллшит просто поражает. Даже интересно бы было увидеть пример обязательной игры. Воображение рисует голодные игры или что-то подобное.
Свалили всё в кучу, посчитали какие-то формальные критерии, которые иногда коррелируют с востребованностью языка, а иногда нет. Не учтён важнейший фактор — сферы применения каждого языка. Без этого невозможно понять, какие языки действительно конкурируют между собой, и кто из них действительно является лидером в своей нише. Даже интересно, у этого индекса есть хоть какая-то полезность? Лично мне кажется, что нет, но может я что-то упускаю?
А вообще, пример, конечно, притянут за уши. Обычно, приватные конструкторы нужны для реализации синглтонов. Но в JS можно реализовать синглтон и без этого.
По вкусу, можно добавить выбрасывание ошибки при повторном явном вызове конструктора, статический метод getInstance, ну и т.д.
На вскидку, сложно сказать, насколько реально нужен приватный конструктор в JS, но он уж точно не является приоритетом. Вот чего не хватает, так это модификатора protected. Уж если начали модификаторы доступа добавлять, не стоило останавливаться на private.
От слова «комплементарный» тоже лучше избавиться. Почему не сказать просто «дополнительный»? Дополнительный аспект, дополнительное обстоятельство, дополнительный смысл. Не нужно никаких сложных слов, там где можно обойтись простыми.
Уверен, и прочую терминологию можно упростить. При этом, основная идея не пострадает, а наоборот станет только понятнее.
Назначение самих аспектов, лично я бы сформулировал несколько иначе. Может это и вкусовщина, но если давать классификацию, то признак для классификации должен быть единым. Лично я всегда понимал Progressive и Perfect как способы показать относительное положение событий во времени. Как правило, нам может быть важно, пересеклись ли события во времени (одновременность событий), и какое из них предшествовало другому (последовательность событий). В итоге, получается такая классификация:
Simple — Основной аспект. Просто факты. Что, когда, как часто происходило, происходит, будет происходить. Нет указания на отношения с другими событиями.
Progressive — указывает на одновременность нескольких событий, пересечение их во времени. Внезапно, пересечение во времени сложно показать без указания на то, что хотя бы одно из событий не было моментальным, т.к. редко что-то происходит абсолютно одновременно. Какое-то событие, как правило, начинается раньше, и длится некоторое время прежде чем пересечётся во времени с другим событием. Так же, стоит отметить, что текущий момент всегда происходит одновременно с разговором, поэтому для него тоже используется Progressive.
Perfect — указывает на последовательность событий, предшествование одного другому. Для этого одно из событий должно завершиться до начала другого, поэтому требуется совершенная форма.
Perfect Progressive — указывает на последовательность и в то же время, на пересечение событий во времени. Иногда нам важно, и то что события пересеклись во времени, и то что одно из них началось раньше. Раз уж нам важны такие нюансы, как правило, важно ещё и насколько раньше одно из событий началось, как долго оно продолжалось, поэтому, такая информация здесь указывается явно.
Самое главное, при такой классификации, даже не надо отдельно оговариваться что все аспекты, кроме Simple, являются составными, и требуют указания второго события или наличия контекста, ведь речь идёт об относительном положении событий во времени.
Пока не будет найдена собственная цель, нет смысла говорить о каких-то там цивилизациях, какого-либо типа. Живая масса без собственной цели — это не цивилизация, поглоти она хоть энергию всей Вселенной. Цивилизация тем и отличается от всех остальных форм организации материи, что она создаётся разумными существами. Если существа не понимают, зачем они существуют, их сложно назвать разумными в полной мере. У людей пока только есть потенциал осознать себя, но они его ещё не реализовали. А до тех пор, мы даже не знаем, нужно ли нам увеличивать масштаб нашей «цивилизации». Не зная к чему хочешь придти, глупо выбирать путь. Это как искать ответ, не зная вопроса.
Давайте проведём аналогию с играми, раз уж автор приводит пример с игрой из детства. Если подумать, игры здесь очень хорошо подходят в качестве модели. Думаю, любой человек с солидным игровым опытом, не раз сталкивался со сложными уровнями или миссиями в играх, для прохождения которых требовалось предпринимать десятки, а то и сотни попыток. Вспомните 3-й уровень в Battletoads, где нужно ездить на байке, миссию с вертолётиком в GTA Vice City или миссию с гонкой в первой Мафии. Признаюсь честно, иногда я бросал игры из-за таких миссий, например, я так и не прошёл первую Мафию.
Программирование напоминает именно такие игры. Посреди простых и умеренно сложных задач, периодически встречаются особенно сложные «миссии». Но ведь эта неравномерность объективно увеличивает общую сложность всей задачи, причём, вовсе не за счёт вклада в среднюю сложность, а гораздо сильнее. Легко обмануться, приняв среднюю сложность за общую, но чтобы достичь цели, надо пройти весь путь, а для этого вам должна быть по плечу не только средняя его сложность, но и пиковая. Следовательно, сложность всего пути не равна средней сложности всех его участков. Простое среднее — это лишь минимально возможная сложность, если считать что распределение сложности по участкам близко к равномерному. Неравномерность существенно влияет на общую сложность в сторону её увеличения, по сравнению со средней, и это не субъективное восприятие, а объективный факт.
Можно долго рассуждать о психологии, стойкости, упорстве, готовности терпеть неудачи, и т.д. Но глупо при этом отрицать, что всё это требуется, прежде всего, при решении объективно сложных задач. То что сложные задачи являются ещё и серьёзным психологическим испытанием, это лишь положительная обратная связь. Чем агрессивнее внешние условия, чем ближе режим работы к пределам возможностей, тем выше вероятность, что проявятся ещё и внутренние проблемы. В этом нет никакого откровения. Это просто очевидно.
Может в английском «we have» и звучит нормально, в данном контексте, но по русски это звучит просто смешно. Статья, сама по себе, очень слабая, и местами даже вредная, но вам удалось её ухудшить.
Ещё и пропустили абзац про Multiple Frames and Windows. Это важное ограничение instanceof. Я было хотел поругать автора за то, что не упомянул это, но в английском оригинале про это написано, хотя и без детальных пояснений.
А вот за это автору оригинала надо поставить двойку. Формально, оператор instanceof действительно сработает для примитива, если тот был создан с помощью new. Но говорить что он в этом случае полезен — это преступление. Напротив, это выстрел в ногу. В том участке кода, где вам может понадобится проверка, вы никогда не будете знать, как было создано значение, вы не можете знать, использовался ли оператор new или нет, следовательно, не можете на это полагаться. Вы потому и проверяете, что не знаете, что там. Поэтому, никогда нельзя проверять с помощью instanceof те типы, для которых есть отдельное значение у оператора typeof: string, number, boolean, bigint, symbol.