Как стать автором
Обновить
22
0
Алексей @pankraty

Разработчик

Отправить сообщение

И ещё, чтобы тепловая карта показывала объективный результат, величина ячеек должна быть одинаковой на всей площади. Иначе даже абсолютно равномерное распределение точек будет визуализировано как имеющее бОльшую плотность в той части, где ячейки крупнее. Поэтому проекцию стоит выбирать равновеликую.

Как зарядка для ума - неплохое упражнение. С практической точки зрения - вариант не очень универсальный.

Думаю, проблемы с подсчётом расстояний между между точками с использованием geography были вызваны тем, что вы считали расстояния от каждой точки до каждой, что, очевидно, слишком ресурсозатратно. Правильнее было бы спроецировать географические координаты в целевую СК (в ту, в которой будет происходить отображение), а в ней уже кластеризовать по квадратной сетке нужного размера. В вашем же случае сделать сетку квадратной, а не прямоугольной или трапецевидной - задача нетривиальная.

Не может, т.к. в английском idiot ударение на первый слог, а настолько недослышать - это надо очень постараться.

Мне стоило бы обновить комменты перед отправкой...

Но мне непонятно, что мешает извлечь коммит 5-летней давности, провести проверку, зафиксировать ошибки, извлечь последний коммит и провести повторную проверку.

Статья называется "Представляем Q# Formatter", а по факту её содержимое больше напоминает release notes очередной версии продукта, который уже хорошо знаком читателям.

Поэтому в этот раз я проделал довольно много дополнительной работы, чтобы исключить из отчёта ранее найденные ошибки.

Как-то это плохо стыкуется с утверждениями из статей про внедрение PVS Studio на больших проектах, о том, что можно запустить анализ, пометить всё ошибки как "базовый уровень", и в последующих анализах видеть только новые ошибки. Я думал, это делается в несколько кликов.

А мне персонаж Сутеева представлялся

Собственно, данная статья и работает в пользу приведения ожиданий людей к реальности.

Так это просто для иллюстрации того, сколько раз выполняется сравнение. Когда коллекция большая, а сравнение медленное, могут возникнуть проблемы, там где их не ждёшь. А захват тут не при чем.

Кроме того, это никак р-не противоречит моему доводы о том, что "простая мнемоника никогда не делайте multiple enumeration по enumerable" снимает не все проблемы.

Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны. И то, что несколько человек на этом попались, опровергает тезис "нельзя".

Увы не полностью. С единственным вызовом 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 (параллельно с десятком-другим разработчиков, делающих свои коммиты) , и их надо творчески отреверсить, ничего не пропустив и не сломав никакого кода, который потенциально с ним связан. Риски, что что-то "отъедет", весьма велики.

Информация

В рейтинге
Не участвует
Откуда
Саратов, Саратовская обл., Россия
Дата рождения
Зарегистрирован
Активность