Увы не полностью. С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца, но легко упустить, что после Where мы имеем дело не с массивом (как вы уже написали ниже), и обход будет полным. Так что пусть пример несколько синтетический, но полезная информация в нём определённо есть, чтобы не попадаться на таких ловушках.
цинк-65, чья радиоактивность будет гораздо выше на начальном этапе и, соответственно, спадет быстрее. Но этот изотоп составляет лишь примерно половину природного цинка, поэтому для военного применения его пришлось бы обогащать.
Вряд ли его стали бы обогащать, если бы решили использовать в качестве оружия. Просто смирились бы с КПД 1/2 от теоретического (если конечно можно назвать такое "действие" "полезным")
Так ведь есть исследования, что будучи изолированным от внешней среды (например, в пещере), организм имеет тенденцию переходить на удлинённый цикл сна/бодрствования. Там, конечно, много факторов оказывают влияние, но в межзвёздных странствиях нет объективных предпосылок против установления размера цикла в 100 Кс (27:46 на наши деньги). Жаль в СИ не предусмотрено стандартной приставки для 100 000
Проблемы с календарями во многом вызваны стремлением сохранить привязку к природным циклам - т.е. приравнять год к периоду обращения Земли вокруг Солнца, а сутки - к периоду оборота вокруг оси. В, условно, стандартном галактическом времени это не имело бы смысла, там логичнее было бы измерять время кило-, мега-, гигасекундами. Например, в течение одной Мс рабочему предоставляется 300Кс выходных, кроме того ему полагается оплачиваемый отпуск в 1Мс один раз в 20Мс... Операции с датами станут тривиальными, а вот перевод в архаичные земные единицы останется всё таким же заморочным.
(Удивляет, что во всякой космической фантастике продолжают считать время земными единицами; впрочем, я тут не очень начитан)
Поддержу. У нас американский ПМ, когда отключается от созвона, обычно говорит "I'm bailing". Brolly в значении "зонтик" буквально недавно впервые услышал, причём от британцев.
Я когда сыроделием увлекался, столкнулся со сложностями перевода. В русском языке на разных стадиях вы имеет дело со сгустком, сырным зерном, сырной массой, сырным тестом. А в английском это всё называется curd. И творог тоже curd (либо cottage cheese). И омонимичность слов "плесень" и "форма" (то и другое mold) тоже иногда мешает, впрочем, не слишком сильно, обычно из контекста понятно.
Мне кажется, дело тут не столько в том, насколько "умён" DI-фреймворк, а в том, что в разных ситуациях разработчику может требоваться разное поведение - иногда ему принципиально важно получить один и тот же экземпляр, внедряя зависимость по любому из его интерфейсов, а в других случаях - принципиально важно, чтобы создавался новый экземпляр. DI от Microsoft предоставляет возможность это сделать, а значит свою задачу решает (пусть и не самым интуитивным образом). Тем более что в подавляющем большинстве случаев это вообще не имеет значение, т.к. класс регистрируется по одному интерфейсу.
Да и я бы не сказал, что принцип дурацкий; при написании кода мы практически всегда стараемся в той или иной мере ему следовать, пуусть и неосознанно. Например (в C#), переопределяя метод ToString, обычно никто не будет выбрасывать исключений, а спроси почему это плохая идея - ответят, что вызывающий код может не знать, что объект такого типа требует особого обращения, и вызвать ToString, и неожиданно упасть. Или, к примеру, реализуя метод Equals, технически мы можем делать всё что угодно, хоть картинки котиков показывать, но обычно мы туда помещаем логику сравнения объектов, потому что это именно то, что ожидает потребитель интерфейса.
Так это же и есть проявления принципа Лисков, к которым мы привыкли и воспринимаем как данность. Ну так и многие "принципы", "паттерны", "законы" лишь формализуют то, что давно известно и применяется. Так вот живешь и не знаешь, что всю жизнь говорил прозой.
При таком подходе даже если вы что-то напишете не так, то быстро и легко сможете это поправить. Есть еще дополнительный бонус от такого подхода. Когда программист что-то долго пишет и где-то в начале уходит не туда, он может идти не туда целую неделю и даже больше. В результате накопленный негативный эффект будет слишком большой. Но если бы он вливал в main очень маленькими кусочками, то вы бы намного раньше увидели, что он пошел не в ту сторону, и поправили это.
Вот тут не могу согласиться. Одно дело, когда разработчик неделю писал в своей ветке что-то не то - да, он потратил время, но ущерб проекту на этом заканчивается. И совсем другое дело, когда он за эту неделю сделал 50 мелких коммитов в trunk (параллельно с десятком-другим разработчиков, делающих свои коммиты) , и их надо творчески отреверсить, ничего не пропустив и не сломав никакого кода, который потенциально с ним связан. Риски, что что-то "отъедет", весьма велики.
Как технику тяжело читать при таком количестве грубых англицизмов. Неужели так трудно соблюдать строгость терминологии и при переводе применять полный нативный термин, как это принято во всей академической литературе.
На эту тему попадался короткий рассказ - довольно забавный, но я не помню ни автора, ни названия. Там в Солнечную систему прибыли представители негуманоидной цивилизации, у которых восприятие времени на несколько порядков более медленное, чем у нас. С их точки зрения, буквально на их глазах, на одной из планет возникла и взрывоподобно развилась разумная жизнь на основе углерода.
закончилось печально
Космический корабль землян обнаружил пришельцев, по-видимому, чрезвычайно древний. Признаков жизни ре обнаружено, всё обитатели представляют собой окаменелости, которые было решено выставить в музее.
И только уборщик недоумевал, почему эти окаменелости периодически оказывались сдвинуты на несколько миллиметров, и раз за разом ставил их на место.
Да, когда у кого-то вертикальный полноразмерный монитор, а у собеседников ноутбуки, то демонстрация экрана превращается в боль. Особенно в Тимсе, который сверху и снизу добавляет весьма немаленькие поля.
На одном проекте у нас прям кладезь утечек был, на статью бы хватило. Большую часть уже не вспомню, но самые любопытные примеры запомнились.
Простой паттерн - отписаться от события, изменить коллекцию и подписаться обратно. Но если подписка/отписка сделана через анонимные методы, то отписка не делает ничего, а подписка - добавляет ещё один делегат. Пишу схематично, с телефона
Причины понятны, анонимный делегат каждый раз создаётся новый, поэтому отписка не происходит. Но пропустить такое довольно легко.
Window.ShowDialog() имеет задокументированную, но легко пропускаемую особенность: когда вызван без параметров, то родительским элементом для нового окна станет главное окно приложения. И когда в системе открывается большое количество диалоговых окон (в том числе, одно из другого, а из него ещё одно и т. д), со сложными моделями и со множеством взаимосвязей, то память кушается очень активно, а освобождается только при закрытии главного окна. Как решали, точно не помню - то ли явным образом вызывали диспоуз, то ли передавали параметр в ShowDialog, чтобы дочерние диалоги диспозилизь при закрытии родительского.
Ещё в системе были WPF элементы, встроенные в WinForm элементы (посредством ElementHost), а в паре мест было наоборот - WinForm-овский WebBrowser встраивался в WPF окно. И на WinForm всё привыкли, что диспоуз родителя диспозит всех детей, а на WPF всё привыкли, что Dispose не требуется, поэтому в ElementHost даже не предусмотрен диспоуз вложенной вьюшки, даже если она реализует IDisposable. Кто ж знал, что туда внутрь вкрутят браузер, который обязательно надо задиспоузить? Пришлось какие-то костыли прикручивать.
Вообще, конечно, яркий проект был. На thedailywft.com штук 8 статей по его мотивам.
Большую часть "недостатков" можно отнести к любой профессии. Кем бы вы ни работали, вы как рабочая единица будете "функцией", от которой ожидается выполнение поставленной задачи ("вы всего лишь инструмент"), расходы на которую будут стремиться минимизировать для увеличения прибыльности ("вы обуза"); "профессия" предполагает, что вы не единственный в мире специалист, а в той или иной мере представляете класс специалистов в определенной области ("вы заменяемы"). Насчёт устаревания - вероятно, где-то ещё сохранились профессии, где не требуется изучение нового, чтобы оставаться востребованным (и высокооплачиваемым), но их всё меньше, и да в IT давление нового особенно сильно; для кого-то это минус, а для кого-то наоборот жирный плюс.
Так в чем в итоге посыл статьи? Бросайте %JOB_NAME%, потому что вы всего лишь инструмент, становитесь... А собственно кем? Где тот идеал, по мнению автора, который лишён перечисленных недостатков?
Увы не полностью. С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца, но легко упустить, что после Where мы имеем дело не с массивом (как вы уже написали ниже), и обход будет полным. Так что пусть пример несколько синтетический, но полезная информация в нём определённо есть, чтобы не попадаться на таких ловушках.
Вряд ли его стали бы обогащать, если бы решили использовать в качестве оружия. Просто смирились бы с КПД 1/2 от теоретического (если конечно можно назвать такое "действие" "полезным")
Так ведь есть исследования, что будучи изолированным от внешней среды (например, в пещере), организм имеет тенденцию переходить на удлинённый цикл сна/бодрствования. Там, конечно, много факторов оказывают влияние, но в межзвёздных странствиях нет объективных предпосылок против установления размера цикла в 100 Кс (27:46 на наши деньги). Жаль в СИ не предусмотрено стандартной приставки для 100 000
Проблемы с календарями во многом вызваны стремлением сохранить привязку к природным циклам - т.е. приравнять год к периоду обращения Земли вокруг Солнца, а сутки - к периоду оборота вокруг оси. В, условно, стандартном галактическом времени это не имело бы смысла, там логичнее было бы измерять время кило-, мега-, гигасекундами. Например, в течение одной Мс рабочему предоставляется 300Кс выходных, кроме того ему полагается оплачиваемый отпуск в 1Мс один раз в 20Мс... Операции с датами станут тривиальными, а вот перевод в архаичные земные единицы останется всё таким же заморочным.
(Удивляет, что во всякой космической фантастике продолжают считать время земными единицами; впрочем, я тут не очень начитан)
Поддержу. У нас американский ПМ, когда отключается от созвона, обычно говорит "I'm bailing". Brolly в значении "зонтик" буквально недавно впервые услышал, причём от британцев.
Я когда сыроделием увлекался, столкнулся со сложностями перевода. В русском языке на разных стадиях вы имеет дело со сгустком, сырным зерном, сырной массой, сырным тестом. А в английском это всё называется curd. И творог тоже curd (либо cottage cheese). И омонимичность слов "плесень" и "форма" (то и другое mold) тоже иногда мешает, впрочем, не слишком сильно, обычно из контекста понятно.
Мне кажется, дело тут не столько в том, насколько "умён" DI-фреймворк, а в том, что в разных ситуациях разработчику может требоваться разное поведение - иногда ему принципиально важно получить один и тот же экземпляр, внедряя зависимость по любому из его интерфейсов, а в других случаях - принципиально важно, чтобы создавался новый экземпляр. DI от Microsoft предоставляет возможность это сделать, а значит свою задачу решает (пусть и не самым интуитивным образом). Тем более что в подавляющем большинстве случаев это вообще не имеет значение, т.к. класс регистрируется по одному интерфейсу.
Да и я бы не сказал, что принцип дурацкий; при написании кода мы практически всегда стараемся в той или иной мере ему следовать, пуусть и неосознанно. Например (в C#), переопределяя метод ToString, обычно никто не будет выбрасывать исключений, а спроси почему это плохая идея - ответят, что вызывающий код может не знать, что объект такого типа требует особого обращения, и вызвать ToString, и неожиданно упасть. Или, к примеру, реализуя метод Equals, технически мы можем делать всё что угодно, хоть картинки котиков показывать, но обычно мы туда помещаем логику сравнения объектов, потому что это именно то, что ожидает потребитель интерфейса.
Так это же и есть проявления принципа Лисков, к которым мы привыкли и воспринимаем как данность. Ну так и многие "принципы", "паттерны", "законы" лишь формализуют то, что давно известно и применяется. Так вот живешь и не знаешь, что всю жизнь говорил прозой.
Вот тут не могу согласиться. Одно дело, когда разработчик неделю писал в своей ветке что-то не то - да, он потратил время, но ущерб проекту на этом заканчивается. И совсем другое дело, когда он за эту неделю сделал 50 мелких коммитов в trunk (параллельно с десятком-другим разработчиков, делающих свои коммиты) , и их надо творчески отреверсить, ничего не пропустив и не сломав никакого кода, который потенциально с ним связан. Риски, что что-то "отъедет", весьма велики.
Какая ирония
Точно! Спасибо большое! Поставлю прямую ссылку https://lleo.me/arhive/fan2004/na_mesto.shtml
На эту тему попадался короткий рассказ - довольно забавный, но я не помню ни автора, ни названия. Там в Солнечную систему прибыли представители негуманоидной цивилизации, у которых восприятие времени на несколько порядков более медленное, чем у нас. С их точки зрения, буквально на их глазах, на одной из планет возникла и взрывоподобно развилась разумная жизнь на основе углерода.
закончилось печально
Космический корабль землян обнаружил пришельцев, по-видимому, чрезвычайно древний. Признаков жизни ре обнаружено, всё обитатели представляют собой окаменелости, которые было решено выставить в музее.
И только уборщик недоумевал, почему эти окаменелости периодически оказывались сдвинуты на несколько миллиметров, и раз за разом ставил их на место.
Прочитал статью и пролистывал комментарии, недоумевая, почему никто не указал на очевидную абсурдность бенчмарка.
Вы все неправильно поняли!
Вот так правильно
Монитор захлопнул и домой.
Да, когда у кого-то вертикальный полноразмерный монитор, а у собеседников ноутбуки, то демонстрация экрана превращается в боль. Особенно в Тимсе, который сверху и снизу добавляет весьма немаленькие поля.
Представил себе выпуск Mythbusters на эту тему - как раз по их профилю
Ну что вы ей-богу. Из следующей даты вычесть текущую! Как два пальца
На одном проекте у нас прям кладезь утечек был, на статью бы хватило. Большую часть уже не вспомню, но самые любопытные примеры запомнились.
Простой паттерн - отписаться от события, изменить коллекцию и подписаться обратно. Но если подписка/отписка сделана через анонимные методы, то отписка не делает ничего, а подписка - добавляет ещё один делегат. Пишу схематично, с телефона
Причины понятны, анонимный делегат каждый раз создаётся новый, поэтому отписка не происходит. Но пропустить такое довольно легко.
Window.ShowDialog() имеет задокументированную, но легко пропускаемую особенность: когда вызван без параметров, то родительским элементом для нового окна станет главное окно приложения. И когда в системе открывается большое количество диалоговых окон (в том числе, одно из другого, а из него ещё одно и т. д), со сложными моделями и со множеством взаимосвязей, то память кушается очень активно, а освобождается только при закрытии главного окна. Как решали, точно не помню - то ли явным образом вызывали диспоуз, то ли передавали параметр в ShowDialog, чтобы дочерние диалоги диспозилизь при закрытии родительского.
Ещё в системе были WPF элементы, встроенные в WinForm элементы (посредством ElementHost), а в паре мест было наоборот - WinForm-овский WebBrowser встраивался в WPF окно. И на WinForm всё привыкли, что диспоуз родителя диспозит всех детей, а на WPF всё привыкли, что Dispose не требуется, поэтому в ElementHost даже не предусмотрен диспоуз вложенной вьюшки, даже если она реализует IDisposable. Кто ж знал, что туда внутрь вкрутят браузер, который обязательно надо задиспоузить? Пришлось какие-то костыли прикручивать.
Вообще, конечно, яркий проект был. На thedailywft.com штук 8 статей по его мотивам.
Большую часть "недостатков" можно отнести к любой профессии. Кем бы вы ни работали, вы как рабочая единица будете "функцией", от которой ожидается выполнение поставленной задачи ("вы всего лишь инструмент"), расходы на которую будут стремиться минимизировать для увеличения прибыльности ("вы обуза"); "профессия" предполагает, что вы не единственный в мире специалист, а в той или иной мере представляете класс специалистов в определенной области ("вы заменяемы"). Насчёт устаревания - вероятно, где-то ещё сохранились профессии, где не требуется изучение нового, чтобы оставаться востребованным (и высокооплачиваемым), но их всё меньше, и да в IT давление нового особенно сильно; для кого-то это минус, а для кого-то наоборот жирный плюс.
Так в чем в итоге посыл статьи? Бросайте %JOB_NAME%, потому что вы всего лишь инструмент, становитесь... А собственно кем? Где тот идеал, по мнению автора, который лишён перечисленных недостатков?
Может, потому что этот устойчивый оборот имеет корни в конном спорте?