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

Разработчик

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

В общем-то незачем, конечно (впрочем, и без интерполированнных строк в константах можно было жить), просто выглядит неконсистентно. Это как разрешить операцию сложения только для многозначных чисел, но не для однозначных

Скажем так, я не настаиваю, что это единственно правильное решение, но считаю рациональным "нормализовать" входные данные, приводя их к нулевому часовому поясу (да, UtcNow), а при отображении - приводить к часовому поясу пользователя.

Аналог: если система поддерживает различные единицы измерения, вы вряд ли будете хранить в одном столбце "19 м", " 140 дюймов", "4 фута". Скорее всего, всё будет преобразовано к одной единице измерения, а потом оттбражатся в виде, удобном пользователю. Исключение - когда это приводит к недопустимой потере точности; в таком случае хранение в разных единицах оправдано.

Но при наследовании есть одна особенность: переопределенный вами метод ToString не будет унаследован потомками от родительской записи. Для того чтобы потомки записей наследовали метод ToString, стало доступно использование ключевого слова sealed, которое запрещает компилятору генерировать имплементацию метода ToString у дочерних записей.

Выглядит как баг, который оказалось настолько сложно исправить, что пришлось запилить костыль, работающий для некоторых случаев. А если я хочу использовать родительскую имплементацию ToString во всех наследниках кроме одного-двух? Тупик, метод запечатан, его уже не переопределить.

Интересный факт. Данное нововведение относится к интерполированию строк, то есть добавление константного символа не допускается:

Очень странная, ничем не обоснованная особенность. Недоделка, которую исправят в С# 11?

Когда данные собраны в базу из разных источников, в подавляющем большинстве случаев неважно знать, какой часовой пояс использовал пользователь/система в момент отправки данных. В тех случаях, когда это важно, DateTimeOffset вполне оправдан. В других - скорее избыточен, т.к. занимает вдвое больше места.

некоторые фильмы сильно лучше в нашей озвучке (многие даже не понимают почему на западе некоторые роли некоторых актеров считаются крайне плохими, так как смотрели в озвучке)

Так-то да, но контрпримеров много больше.

У нас в базе есть таблица, в которой сохраняются события перед отправкой в очередь, чтобы гарантировать, что они будут отправлены только при успешном коммтте транзакции (a.k.a. transactional outbox pattern). Проблема с такой таблицей в том, что она непрерывно растет и нуждается в периодической очистке, поскольку обработанные события хранить не обязательно.

Чтобы сделать очистку безболезненной, я придумал такое решение (но ещё не реализовывал на практике; любопытно услышать стороннее мнение, какие могут быть подводные камни, которые я не учел):

  1. Делим таблицу на три партиции - A, B, C

  2. Ключом партиционирования делаем (в качестве примера) текущий час, разделенный на 8 (с округлением вниз до целого) . Т.е. данные будут циклически попадать в одну из партиций A, B или C, в зависимости от времени суток. Размер можно подобрать в зависимости от нагрузки, важно, чтобы протяженность окна одной партиции была заведомо длиннее самой долгой транзакции, возможной в системе. Чтобы спалось спокойнее, можно брать хоть остаток от деления текущего месяца на 3 - принцип не меняется, только увеличивается объем хранимых данных.

  3. По расписанию, вскоре после того, как текущей становится партиция C, партиция А очищается (через truncate), когда активной становится партиция A, чистим B, когда активной становится B, чистим C.

  4. Перед очисткой убеждаемся, что в партиции не осталось необработанных строк. Для обработчика уже существует partial index по условию processed=false, поэтому такой запрос нересурсозатратный. Если строки найдены, копируем их в отдельную таблицу. Ввжно, что наличие "старых" необработанных строк - признак аварии, в норме их быть не должно вовсе. Поэтому таблица с копиями бесконтрольно разрастаться не будет. После устранения аварии и переотправки событий она будет очищаться.

POC, набросанный на скорую руку, показал жизнеспособность идеи, но под промышленной нагрузкой не тестировал.

Может быть, я переизобрел какой-то известный велосипед? Что думаете?

Единственная информация в объявлении, которую можно условно считать достоверной, это номер телефона для связи. Ко всему остальному стоит относиться предвзято. Это огромная и довольно дикая индустрия, в которой вас будут пытаться обмануть на каждом шагу. Так что верить можно только тому, что вы проверили лично и/или с помощью профессионалов, которым доверяете (и то возможны ошибки), и уж точно не тому, что вычислил искусственный интеллект условного авто.ру.

Увы, получился 100501-ый ликбез на тему, что такое транзакция и ACID.

Тут уже многие оттоптались по пляшущим цифрам, и я к ним присоединяюсь - для меня это единственный серьезный недостаток Calibri. На мой, сугубо обывательский, вкус, прыгающие цифры в записи многозначных чисел смотрятся неряшливо, а вовсе не изысканно.

И вот мне подумалось. Выше писали, что в Англии от руки цифры записывают именно так, с выносными элементами вверх и вниз. И если это так, это многое объясняет: те, кто с детства привык писать цифры таким образом, воспринимает шрифты с таким написанием как норму. Но в нашей традиции цифры пишутся высотой как заглавные буквы, и большинство комментаторов привыкли именно к такому варианту, поэтому свешивающие цифры воспринимают как неестественные.

Это как с китайскими иероглифами. На наш вкус массив текста на китайском воспринимается как сплошная стена, без акцентов. Все символы одной высоты и практически одинаковые по ширине. Но переверстайте их по-европейски, с выносными элементами то вверх, то вниз, и посмотрите, как такой текст будут воспринимать урожденные китайцы. Более чем уверен, они не оценят красоты.

Простой и дешевый способ избавиться от оттопыриваний - НАБИРАТЬ ВСЕ КАПСОМ. Идеально ровные строчки получаются, особенно, если от запятых избавиться.

Так не вопрос как перевести смысл. Вопрос в том чтобы сделать это одним словом, вся статья об этом. Weekly, monthly - переводится, biweekly - нет.

Biweekly meeting - ежеполмесячная встреча?

Fortnight как "полмесяца" в принципе, возможно, но не всегда точно. See you in fortnight подразумевает "через две недели ровно", а "Через полмесяца" - весьма приблизительно. Но на практике обычно нет проблемы перевести двумя словами, действительно.

На предложение перевести Feature как Особенность - кто такой Feature Owner?

Из айтишного навскидку Feature, Commit, Contributor, Partition/Partitioning, Shard/Sharding.

Из неайтишного - Fortnight, Biweekly. Opportunity vs Possibility.

Немного из другой серии, но тоже из разряда бесполезного - это возможность иметь internal abstract член в публичном классе. Если унаследоваться из внешней сборки, переопределять этот член нельзя, т.к. он internal, но не переопределять тоже нельзя, т. к. он абстрактный. Такой вот курьез. Вроде и не баг, но и практической пользы ноль. Будет интересно, если кто-то придумает юзкейс, в котором это применимо.

Ещё одна вещь, которую вряд ли придумали бы в такой форме, если придумывали сразу, с нуля. "protected internal" является не взаимоусиливающей комбинацией "protected" и "internal", а действует как "или": чтобы получить доступ к члену надо быть наследником ИЛИ (не И) находиться в той же сборке (ср. с private static, например - на него одновременно распространяются ограничения private и static, усиливая друг друга). Зато логическое И выражается в виде модификатора "private protected", хотя от private в нём вообще ничего. Мне кажется, если бы не обратная совместимость, то "protected internal" должен был бы стать тем, что сейчас называется "private protected", а нынешний protected internal (с логическим ИЛИ) должен быть упразднен: если уж член protected, то ему обычно незачем быть публичным внутри своей сборки.

Из моей практики, на одном проекте активно использовались dynamic типы для работы с JSON -ами, приходящими из базы. С одной стороны, не надо делать массу DTO- шек, и если структура документа в базе со временем меняется, то вроде бы как код продолжает работать без необходимости поддерживать сущности v1, v2, vN+1... Но преимущества мнимые, т. к. все начинает падать в рантайме, принося в .Net все "прелести" языков без строгой типизации. Бррр, до сих передергивает, как вспоминаю.

Другой случай, где я применял dynamic, на этот раз самостоятельно, заключался в том, что внешняя библиотека (OpenXML, но это не важно) предоставляла несколько почти идентичных классов, с одинаковым набором полей, но в разных пространствах имён. Никаких общих интерфейсов или предков они не имели. Расширить внешнюю библиотеку тоже нельзя. И нужно было написать конвертацию из обоих типов в наш внутренний, по возможности, избежав копипасты. Для этого у меня было два internal метода, принимающих аргументы из разных пространств имён, и перенаправляющих вызовы в private метод, с dynamic аргументом. Чтобы это все не отвалилось при апгрейде OpenXML, код был плотненько покрыт тестами. И долгое время для меня это был единственный более-менее оправданного применения dynamic на практике, но и то потом оказалось, что это вызывало проблемы у пользователей, работающих в sandbox environment-ах (подробностей не помню, если кому будет интересно, найду соответствующий тикет на гитхабе). Так что и от такого применения пришлось отказаться.

А в защиту query syntax скажу, что тоже не понимал, для чего им вообще пользоваться, пока не столкнулся с запросом, в котором цепочка джойнов добавляла по одному новому полю к анонимному объекту. С query- синтаксисом такой запрос оказался в несколько раз короче, и читается легче.

Хотел пройти мимо, но не смог сдержаться.

Что также является причиной перетасовки членов команды по короткому уведомлению.

Это разве не калька? "Без предупреждения" было бы куда более по-русски.

Хехе, у этого хоррора есть еще сиквел про маленький переиспользуемый пакет, в который вынесены несколько полезных функций, используемых в нескольких проектах. И теперь мало того что изменения логики могут аукнуться в каком-то далеком месте, и тесты этого не покажут; мало того что любые изменения, ломающие API, становятся дикой головной болью... Так еще у этого пакета образовалось несколько внешних зависимостей, и все проекты его использующие обязаны выравнивать версии своих зависимостей, попутно исправляя ломающие изменения, привнесенные их обновлением.

О да, и рекомендательные системы, что в музыке, что на ютьюбе, бесконечно подсовывывающие одно и то же. Блин, у вас есть вся история просмотра, дайте мне что-нибудь новенькое, но не отстоящее на 180 градцсов от плиз интересов! Нет, тебя держат в коконе, рекомендуя одних и тех же "понравившихся исполнителей" и "видео с каналов, которые вы смотрели"

У моих детей сейчас как раз период увлечения лего, и суть в том, что получив новый набор, первый раз они собирают по инструкции именно то, что содержится в наборе. Но следом переключаются на сочетание произвольных деталей из разных наборов, и тут уж какие только Франкенштейны не получаются. Честно говоря, не припомню случая, чтобы поделка "по инструкции" собиралась больше одного раза.

Информация

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