Резонно (интересно, кстати, в каком проценте спам-писем такие трекеры есть?). Но можно и не открывая переместить в спам (что я обычно и делаю). А вот нажатие кнопки "отписаться" – гарантированная отметка.
Угу. И в том же Хаскеле – переопределение операций (в смысле, compile-time полиморфизм, по типам аргументов) в полной мере (благо, строгая типизация гарантирует вызов именно нужной, максимально предсказуемо). Разве что принято следить, чтобы монады оставались монадами и т.п.
Т.е. там, допустим, конкатенация строк плюсом вообще не создаст проблем, потому что вы всегда видите, что складываете строки. Никаких неявных преобразований, какой тип задал – тот и есть
"Любую бинарную операцию можно назвать умножением" – и ведь правда можно :-). Сделать операцию аргументом функции, внутри будет *. Только, конечно, не любую, а ассоциативную и с нейтральным элементом, чтобы предсказуемо работало.
Не буду минусовать :-), но уверенно скажу, что проверка в compile-time всегда происходит раньше проверки в run-time, и получить ошибку компиляции гораздо приятнее, чем крэш у юзера. Это не повод отказываться от проверок в run-time (там, где компилятор не может дать гарантий), но очень облегчает жизнь.
Мне кажется, тут ключевой момент – что товарищу не приходится взаимодействовать ни с коллегами, ни даже с "самим собой месяц назад". Для большинства зарабатывающих программированием ситуация отличается, поэтому нам трудно его понять.
Если ссылаться на математику – то дойдём до того, что тут надо использовать оператор умножения (см. термины "полугруппа", "моноид").
А если всё делать так, чтобы разные сущности всегда обозначались разными символами – может не хватить символов, да и понять не всегда будет просто. Например, деление с остатком и деление floating point чисел (в паскале, к примеру, это действительно две разные операции с разными обозначениями).
Уверенность в типе – гораздо приятнее явных преобразований. Перейти на TypeScript и не бояться, что завтра коллега передаст в вашу функцию строку вместо числа (или наоборот, не добавит у своей функции новый аргумент, без которого вы получите баг в совершенно другом месте кода) – кайф и отдохновение души.
При увеличении нагрузки Polling может стать бутылочным горлышком. Такую проблемку можно решить увеличением интервала между запросами в моменты низкой активности и его уменьшение в пиковые часы.
"с зажатой клавишей ⌃ Control нажать на иконку утилиты правой кнопкой мыши" – полагаю, косяк правки текста? Хотели написать про правую кнопку мыши, но вспомнили, что не у всех она настроена, и надо вместо этого просто нажимать кнопку (какую придётся) с Control?
Логично. Но я, собственно, к тому, что упоминание гарвардской архитектуры в заголовке не имеет отношения к тому, что описано в статье. С тем же успехом вы могли написать "на микроконтроллерах, которые я купил в таком-то магазине" – вроде и правда, но отношения к делу не имеет.
Всё ждал, где же в статье будет про специфику загрузки на гарвардской архитектуре, думал, может, какой-то хитрый хак. И тут раз – и лёгким движением рук (MMU) гарвардская архитектура превращается в фон неймановскую (точнее, реальная архитектура вообще не важна [код не видит, какие шины есть], а с софтовой точки зрения – никаких отличий от фон неймановской).
Если жечь метан – точно выше 1085 градусов цельсия (но она и без поддува выше, тонкая медная проволочка плавится). Вроде на воздухе достижимо до 1500 (думаю, с февкой столько не вытянете, но...), с кислородом – выше 2000. Но, собственно, упирается не столько в достижимую температуру, сколько в то, насколько большой предмет можете до неё нагреть.
У меня не было тогда ЛАТР, а оный пылесос (вроде старый ГДР-овский года этак 80-го - такой типа швабры, корпус с движком и мешком для пыли прямо на ручке) прослужил до полного морального устаревания, моторесурс не исчерпался.
30% помечает, как спам. 30 – как "не спам". Думаете, рассылка на итог не попадёт в спам?
It depends. Если я помню, как подписывался – не спам. Если не помню – спам, рассылка должна быть заблокирована, её хозяева терпеть убытки.
Если я нажму "отписаться" – это в лучшем случае поможет лично мне, в худшем – мне же навредит. Важно именно пожаловаться на спам.
Возможно, там вызывает сомнение сам факт, что письмо с этого адреса (прошло через сомнительный relay).
Вы кнопкой пользуетесь для рассылок, на которые специально или случайно (обычно при регистрации на сайте) подписались или именно для спам-рассылок?
Резонно (интересно, кстати, в каком проценте спам-писем такие трекеры есть?). Но можно и не открывая переместить в спам (что я обычно и делаю). А вот нажатие кнопки "отписаться" – гарантированная отметка.
Ну да. Поэтому если я помню, откуда взялась эта рассылка – я отписываюсь, если нет – просто отправляю в спам, пусть классификатор учится.
А кто-то жмёт "отписаться" на спам-письмах? Это ж значит сказать спамеру – вот мол, я живой, можно этот адрес подписать ещё на 10 рассылок.
Угу. И в том же Хаскеле – переопределение операций (в смысле, compile-time полиморфизм, по типам аргументов) в полной мере (благо, строгая типизация гарантирует вызов именно нужной, максимально предсказуемо). Разве что принято следить, чтобы монады оставались монадами и т.п.
Т.е. там, допустим, конкатенация строк плюсом вообще не создаст проблем, потому что вы всегда видите, что складываете строки. Никаких неявных преобразований, какой тип задал – тот и есть
"Любую бинарную операцию можно назвать умножением" – и ведь правда можно :-). Сделать операцию аргументом функции, внутри будет *. Только, конечно, не любую, а ассоциативную и с нейтральным элементом, чтобы предсказуемо работало.
Не буду минусовать :-), но уверенно скажу, что проверка в compile-time всегда происходит раньше проверки в run-time, и получить ошибку компиляции гораздо приятнее, чем крэш у юзера. Это не повод отказываться от проверок в run-time (там, где компилятор не может дать гарантий), но очень облегчает жизнь.
Мне кажется, тут ключевой момент – что товарищу не приходится взаимодействовать ни с коллегами, ни даже с "самим собой месяц назад". Для большинства зарабатывающих программированием ситуация отличается, поэтому нам трудно его понять.
Если ссылаться на математику – то дойдём до того, что тут надо использовать оператор умножения (см. термины "полугруппа", "моноид").
А если всё делать так, чтобы разные сущности всегда обозначались разными символами – может не хватить символов, да и понять не всегда будет просто. Например, деление с остатком и деление floating point чисел (в паскале, к примеру, это действительно две разные операции с разными обозначениями).
Уверенность в типе – гораздо приятнее явных преобразований. Перейти на TypeScript и не бояться, что завтра коллега передаст в вашу функцию строку вместо числа (или наоборот, не добавит у своей функции новый аргумент, без которого вы получите баг в совершенно другом месте кода) – кайф и отдохновение души.
Ага – сначала строгий режим, потом линтер, а там и до TypeScript дойдёте... Сколько боли у меня ушло после перехода на TS – трудно даже представить.
Не жили вы при диалапе, раз вас это удивляет.
В случае плохой связи не кэшировать всё локально – путь к лютым тормозам.
При увеличении нагрузки Polling может стать бутылочным горлышком. Такую проблемку можно решить увеличением интервала между запросами в моменты низкой активности и его уменьшение в пиковые часы.Э... А что, long poll ещё не изобрели?
"с зажатой клавишей ⌃ Control нажать на иконку утилиты правой кнопкой мыши" – полагаю, косяк правки текста? Хотели написать про правую кнопку мыши, но вспомнили, что не у всех она настроена, и надо вместо этого просто нажимать кнопку (какую придётся) с Control?
Логично. Но я, собственно, к тому, что упоминание гарвардской архитектуры в заголовке не имеет отношения к тому, что описано в статье. С тем же успехом вы могли написать "на микроконтроллерах, которые я купил в таком-то магазине" – вроде и правда, но отношения к делу не имеет.
Всё ждал, где же в статье будет про специфику загрузки на гарвардской архитектуре, думал, может, какой-то хитрый хак. И тут раз – и лёгким движением рук (MMU) гарвардская архитектура превращается в фон неймановскую (точнее, реальная архитектура вообще не важна [код не видит, какие шины есть], а с софтовой точки зрения – никаких отличий от фон неймановской).
Если жечь метан – точно выше 1085 градусов цельсия (но она и без поддува выше, тонкая медная проволочка плавится). Вроде на воздухе достижимо до 1500 (думаю, с февкой столько не вытянете, но...), с кислородом – выше 2000.
Но, собственно, упирается не столько в достижимую температуру, сколько в то, насколько большой предмет можете до неё нагреть.
У меня не было тогда ЛАТР, а оный пылесос (вроде старый ГДР-овский года этак 80-го - такой типа швабры, корпус с движком и мешком для пыли прямо на ручке) прослужил до полного морального устаревания, моторесурс не исчерпался.