По-моему, то, что тут называют словом "учитель", на самом деле просто ходящий и говорящий учебник. И если избавиться от галлюцинаций, свойственных пока что ИИ, то я как-то ничего страшного в такой замене не вижу. Ученик просто взял другой учебник.
В реальности бывает и так, и эдак. Но личный опыт (у меня он всего на два года меньше) показывает, что густота "я не обязан" и "сделайте за меня" после подобных диалогов сильно снижается, а какие-то простые действия - запоминаются, наконец. А однажды (правда, тому уже лет двадцать как) это даже сподвигло руководителя (случайно услыхавшего и ситуацию до, и сам диалог) отправить весь отдел на курсы начальной компьютерной грамотности.
Странно, что нет информации о том, восстанавливается ли нормальное поведение Excel после удаления этого обновления... причём это не сказано даже в описании обновления в Microsoft KB, хотя в known issues информация о проблеме уже указана.
Их catchphrase - “Я ж вас не учу делать мою работу, вот и вы меня не учите делать вашу, а просто сделайте (что-то за меня, потому что мне лень)”.
- Компьютер - это же обычный рабочий инструмент, да?
- Да.
- А сколько ты в день работаешь за компьютером?
- 2 часа (4 часа, 6 часов, весь день).
- То есть в принципе можно сказать, что компьютер - это твой основной рабочий инструмент, так?
- Ну... так.
- А вот теперь скажи ты мне - какое первое слово приходит на ум о работнике, который не знает и не желает знать основ работы со своим основным рабочим инструментом? По-моему, тут самое подходящее слово - профнепригодность.
"Пастернака не читал, но осуждаю". Вернее, не смотрел саму обучалку и ориентировался только на описание в статье. Но уже вижу то, что считаю очень серьёзным недостатком. Нет системы. Вообще нет, и даже не планировалось. Есть тупое натаскивание на "раздражитель - ответ". Для обезьяны сойдёт - но ей-то будут подсовывать изученные ситуации, в крайнем случае ну очень слегка модифицированные. А вот для компьютерной грамотности, пусть и минимальной, уже маловато. Как я понял из прочтения, есть только "что", но нет "почему именно так, а не иначе". Может, ошибаюсь. Надеюсь, что ошибаюсь. Но если не объяснить ламеру до понимания печёнкой, например, что такое диск, каталог и файл, чем файл отличается от папки, обычная папка от сжатой, расширение файла от типа файла и т.п. - толку не ждите. Дрессировка не переходит в эволюцию, и переход количества в качество тут не работает.
Проверить, работает ли оно, можно ровно одним способом — восстановиться.
Причём эта проверка должна быть проведена позже последнего изменения аппаратной (всегда) и программной (есть существует хоть минимальная вероятность, что изменение может интерферировать с резервированием) конфигурации. В противном случае шанс обнаружить вместо бэкапа тыкву также отличен от нуля.
Она предназначена чтобы консольный вывод на паузу ставить. Загрузка компа это частный случай.
В процедурах BIOS нажатие клавиши Pause отправляло процессор в режим ничего не делания (чуть ли не HLT), пока не прилетит какое аппаратное прерывание (а вот аппаратное прерывание таймера - не возобновляло работу ОС, опять же до полного перехвата, впрочем, на это вряд ли кто отваживался). Достаточно было полностью перехватить прерывание клавиатурного порта (без захода в старую процедуру), чтобы это перестало работать. И тем более это перестаёт работать в современных ОС которые, впрочем, иногда, для некоторых приложений и процессов, они эмулируют аналогичное поведение.
Так что остановка загрузки до перехода от процедур BIOS к загрузчику ОС - это как раз общий случай (да и то исключительно в Legacy mode, а вот для UEFI-загрузки уже не факт), а вот остановка консольного вывода - частный.
когда «количество заказов» в отчёте считают через COUNT(какое-нибудь_поле), потому что так короче писать
Короче, чем COUNT(*)? вы серьёзно?
когда сравнивают два отчёта, написанных разными людьми: один взял COUNT(*), другой COUNT(id), и пока id не пустой, числа совпадают
Вот честно - ещё ни разу ни на одной боевой системе не видел поле id, которое было бы NULLable..
Считаем северных, не‑северных и всех
Что сразу результат-то - сам запрос где? и добавьте в него COUNT(region) - для демонстрации объясняемого.
Пион с пустым регионом не попал ни в одну половину.
Почему "пион"? Чуть выше он ещё был "клиент" - пусть таким бы и оставался..
NOT IN с одним NULL возвращает пустоту
Я бы сказал "с хотя бы одним NULL".
И посчитаем выручку двумя запросами — до присоединения позиций и после
В показанном виде второй запрос выглядит более чем странно - зачем присоединять вторую таблицу, если данные из неё не используются? Почему сразу не включить в выходной набор SUM(qty), пусть даже оно и не имеет физического смысла?
Из этого следует единственная привычка, которая помогает: проверять агрегаты на количестве строк до и после.
Привычка - безусловно вредная.
Ошибка в логике написанного запроса - заложенная в запрос логика не соответствует поставленной задаче. И пытаться проверить корректность этой логики по частным результатам - это ну никуда не годится. Именно потому, что работает в частных случаях, на частных наборах данных. Можно случайно проверить на датасете, который иммунен к допущенной ошибке, можно просто не заметить ошибочность результата. То есть надёжность метода - нулевая. Отвыкайте.
Из седой древности - VESA (?) карты Intel. Те, которые настраивались утилитой proset.exe. При старте утилита определяла имеющиеся карты, а при выборе карты для настройки первым делом предлагала установить для неё МАС-адрес. И, по-моему, ненадёванные карты отображали в текущей настройке именно все нули. А вот ISA (опять же емнип) имели что-то дефолтное ненулевое, но одно и то же или уникальное - убейте не помню.
производитель может сделать MAC-неизменяемым, но это не является обязанностью.
Подавляющее большинство сетевых карт допускает программное, на уровне настроек драйвера карты, изменение MAC. А для карт, поддерживающих MultiVLAN, это и вовсе абсолютно необходимая фича.
Большинство вопросов, которые Вы написали, я планировал рассматривать в следующей статье.
Это великолепно. А то большинство статей как раз и завершается на описании, как оно, когда всё штатно и без проблем. Хотя интереснее-то как раз всякие нештатности, отклонения и необычности. Будем подождать..
Возможен вариант, когда ARP Request является unicast. В этом случае система проверяет адрес уже известного соседа.
Этот вариант неплохо бы если не досконально разобрать, то хотя бы описать.
Что может побудить систему на такую проверку? Как часто будет выполняться такая проверка (главным образом - определяет ли стандарт хоть как-то частоту таких проверок, хотя бы от и до, или всё отдано на откуп системе, хоть вообще не проверяй)? Кто именно ответит в случае, если снаружи произошли изменения, и у целевого МАС уже другой IP, а старый IP принадлежит другому МАС? Может ли система получать ответ не от целевого узла, а от кого-то ещё (например, от DHCP-сервера, который выдал кому-то запрашиваемый адрес и соответственно знает его МАС)?
А также - как ведёт себя система, если мимо пробегает пакет от IP/MAC, который системе пока неизвестен? А если известен IP, но под другим МАС? А если наоборот? Если хоть когда такое учитывается - то только информация из транзитных ARP-пакетов, или и из других типов пакетов тоже?
А вот это может и не сработать, если под термином "распутывать" вы разумеете замену отрезков строго в четвёрке точек. Потому как переход между имеющейся и оптимальной конфигурацией может включать в путь конфигурацию с бОльшим количеством пересечений или бОльшей суммарной длиной отрезков.
Если мы со стороны приложения -- то можно втыкать проверки и ограничения на количества повторяемых элементов: ограничивать количество в IN (?), ограничивать количество OR/AND, ограничивать число элементов в форме, понизить максимальный размер форм
Ограничивать - это экстенсив, от которого мало толку. Логику выполнения на уровне формирования запроса нужно менять. Если встречается что-то типа AND (0=1 OR cat_id=1 OR cat_id=2 OR cat_id=3) из ~десятка (предел определяется экспериментально) или менее вариантов значения - выполняем как написано, иначе сливаем набор критериев во временную таблицу (которую ещё и проиндексировать можно). Одно дополнительное ветвление в интерактивной части кода и два разных шаблона запроса - потери минимальны, зато эффект налицо.
Разве не очевидно что такая конфигурация существует?
Увы, но я не вижу вообще никаких предпосылок к ОЧЕВИДНОСТИ такого утверждения. С вашим утверждением получается вообще ерунда, а не задача - существует ли конфигурация, которая (по вашим словам) очевидно существует.
Задача-то как раз и состоит в том, чтобы установить, всегда ли существует такая конфигурация.
Для каждого варианта посчитаем общую сумму длин всех получившихся отрезков и выберем ту конфигурацию, где эта сумма минимальна
Вполне возможна ситуация, когда конфигураций с одинаковой минимальной суммой несколько. Это касается и дальнейшего рассуждения - 4 точки могут образовывать квадрат/ромб. Придётся доказывать, что среди таких конфигураций существует та, в которой отсутствуют пересечения.
Цель - гарантировать, чтобы минимум двое ответили верно.
Правильно для текущей задачи, но некорректно для дополнения про произвольное число цветов и инопланетян. Корректная формулировка - "гарантировать не более одной ошибки".
?? Медленно и плохо - это совершенно разные вещи, медленно - далеко не всегда плохо. Иногда даже что-то приходится специально замедлять (Digger помните? ну или общеизвестное "Быстро, качественно, дёшево - выберите два из трёх"). Нет в мире совершенства, всегда приходится чем-то жертвовать, и иногда это именно скорость.
То есть рекомендуют для хранения денежных величин и тут же признают, что это весьма дорого.
А что именно тут плохо согласуется-то? По-моему, всё правильно и честно - цитаты вообще о разных вещах говорят, просто они, эти вещи, зависимы. Первая цитата предупреждает, что если нужна точность, то NUMERIC, а не FLOAT/DOUBLE, а вторая дополнительно сообщает, какова будет цена реализации этой требуемой точности.
По-моему, то, что тут называют словом "учитель", на самом деле просто ходящий и говорящий учебник. И если избавиться от галлюцинаций, свойственных пока что ИИ, то я как-то ничего страшного в такой замене не вижу. Ученик просто взял другой учебник.
Учитель - это немножко другое. Имхо.
В реальности бывает и так, и эдак. Но личный опыт (у меня он всего на два года меньше) показывает, что густота "я не обязан" и "сделайте за меня" после подобных диалогов сильно снижается, а какие-то простые действия - запоминаются, наконец. А однажды (правда, тому уже лет двадцать как) это даже сподвигло руководителя (случайно услыхавшего и ситуацию до, и сам диалог) отправить весь отдел на курсы начальной компьютерной грамотности.
Странно, что нет информации о том, восстанавливается ли нормальное поведение Excel после удаления этого обновления... причём это не сказано даже в описании обновления в Microsoft KB, хотя в known issues информация о проблеме уже указана.
- Компьютер - это же обычный рабочий инструмент, да?
- Да.
- А сколько ты в день работаешь за компьютером?
- 2 часа (4 часа, 6 часов, весь день).
- То есть в принципе можно сказать, что компьютер - это твой основной рабочий инструмент, так?
- Ну... так.
- А вот теперь скажи ты мне - какое первое слово приходит на ум о работнике, который не знает и не желает знать основ работы со своим основным рабочим инструментом? По-моему, тут самое подходящее слово - профнепригодность.
- Э-э-э...
"Пастернака не читал, но осуждаю". Вернее, не смотрел саму обучалку и ориентировался только на описание в статье. Но уже вижу то, что считаю очень серьёзным недостатком. Нет системы. Вообще нет, и даже не планировалось. Есть тупое натаскивание на "раздражитель - ответ". Для обезьяны сойдёт - но ей-то будут подсовывать изученные ситуации, в крайнем случае ну очень слегка модифицированные. А вот для компьютерной грамотности, пусть и минимальной, уже маловато. Как я понял из прочтения, есть только "что", но нет "почему именно так, а не иначе". Может, ошибаюсь. Надеюсь, что ошибаюсь. Но если не объяснить ламеру до понимания печёнкой, например, что такое диск, каталог и файл, чем файл отличается от папки, обычная папка от сжатой, расширение файла от типа файла и т.п. - толку не ждите. Дрессировка не переходит в эволюцию, и переход количества в качество тут не работает.
Причём эта проверка должна быть проведена позже последнего изменения аппаратной (всегда) и программной (есть существует хоть минимальная вероятность, что изменение может интерферировать с резервированием) конфигурации. В противном случае шанс обнаружить вместо бэкапа тыкву также отличен от нуля.
В процедурах BIOS нажатие клавиши Pause отправляло процессор в режим ничего не делания (чуть ли не HLT), пока не прилетит какое аппаратное прерывание (а вот аппаратное прерывание таймера - не возобновляло работу ОС, опять же до полного перехвата, впрочем, на это вряд ли кто отваживался). Достаточно было полностью перехватить прерывание клавиатурного порта (без захода в старую процедуру), чтобы это перестало работать. И тем более это перестаёт работать в современных ОС которые, впрочем, иногда, для некоторых приложений и процессов, они эмулируют аналогичное поведение.
Так что остановка загрузки до перехода от процедур BIOS к загрузчику ОС - это как раз общий случай (да и то исключительно в Legacy mode, а вот для UEFI-загрузки уже не факт), а вот остановка консольного вывода - частный.
Короче, чем
COUNT(*)? вы серьёзно?Вот честно - ещё ни разу ни на одной боевой системе не видел поле
id, которое было быNULLable..Что сразу результат-то - сам запрос где? и добавьте в него
COUNT(region)- для демонстрации объясняемого.Почему "пион"? Чуть выше он ещё был "клиент" - пусть таким бы и оставался..
Я бы сказал "с хотя бы одним NULL".
В показанном виде второй запрос выглядит более чем странно - зачем присоединять вторую таблицу, если данные из неё не используются? Почему сразу не включить в выходной набор
SUM(qty), пусть даже оно и не имеет физического смысла?Привычка - безусловно вредная.
Ошибка в логике написанного запроса - заложенная в запрос логика не соответствует поставленной задаче. И пытаться проверить корректность этой логики по частным результатам - это ну никуда не годится. Именно потому, что работает в частных случаях, на частных наборах данных. Можно случайно проверить на датасете, который иммунен к допущенной ошибке, можно просто не заметить ошибочность результата. То есть надёжность метода - нулевая. Отвыкайте.
Из седой древности - VESA (?) карты Intel. Те, которые настраивались утилитой proset.exe. При старте утилита определяла имеющиеся карты, а при выборе карты для настройки первым делом предлагала установить для неё МАС-адрес. И, по-моему, ненадёванные карты отображали в текущей настройке именно все нули. А вот ISA (опять же емнип) имели что-то дефолтное ненулевое, но одно и то же или уникальное - убейте не помню.
Подавляющее большинство сетевых карт допускает программное, на уровне настроек драйвера карты, изменение MAC. А для карт, поддерживающих MultiVLAN, это и вовсе абсолютно необходимая фича.
Это великолепно. А то большинство статей как раз и завершается на описании, как оно, когда всё штатно и без проблем. Хотя интереснее-то как раз всякие нештатности, отклонения и необычности. Будем подождать..
Сорри, это вечернее косоглазие.
del
Этот вариант неплохо бы если не досконально разобрать, то хотя бы описать.
Что может побудить систему на такую проверку? Как часто будет выполняться такая проверка (главным образом - определяет ли стандарт хоть как-то частоту таких проверок, хотя бы от и до, или всё отдано на откуп системе, хоть вообще не проверяй)? Кто именно ответит в случае, если снаружи произошли изменения, и у целевого МАС уже другой IP, а старый IP принадлежит другому МАС? Может ли система получать ответ не от целевого узла, а от кого-то ещё (например, от DHCP-сервера, который выдал кому-то запрашиваемый адрес и соответственно знает его МАС)?
А также - как ведёт себя система, если мимо пробегает пакет от IP/MAC, который системе пока неизвестен? А если известен IP, но под другим МАС? А если наоборот? Если хоть когда такое учитывается - то только информация из транзитных ARP-пакетов, или и из других типов пакетов тоже?
А вот это может и не сработать, если под термином "распутывать" вы разумеете замену отрезков строго в четвёрке точек. Потому как переход между имеющейся и оптимальной конфигурацией может включать в путь конфигурацию с бОльшим количеством пересечений или бОльшей суммарной длиной отрезков.
Ограничивать - это экстенсив, от которого мало толку. Логику выполнения на уровне формирования запроса нужно менять. Если встречается что-то типа
AND(0=1ORcat_id=1ORcat_id=2ORcat_id=3)из ~десятка (предел определяется экспериментально) или менее вариантов значения - выполняем как написано, иначе сливаем набор критериев во временную таблицу (которую ещё и проиндексировать можно). Одно дополнительное ветвление в интерактивной части кода и два разных шаблона запроса - потери минимальны, зато эффект налицо.Увы, но я не вижу вообще никаких предпосылок к ОЧЕВИДНОСТИ такого утверждения. С вашим утверждением получается вообще ерунда, а не задача - существует ли конфигурация, которая (по вашим словам) очевидно существует.
Задача-то как раз и состоит в том, чтобы установить, всегда ли существует такая конфигурация.
Вполне возможна ситуация, когда конфигураций с одинаковой минимальной суммой несколько. Это касается и дальнейшего рассуждения - 4 точки могут образовывать квадрат/ромб. Придётся доказывать, что среди таких конфигураций существует та, в которой отсутствуют пересечения.
Правильно для текущей задачи, но некорректно для дополнения про произвольное число цветов и инопланетян. Корректная формулировка - "гарантировать не более одной ошибки".
?? Медленно и плохо - это совершенно разные вещи, медленно - далеко не всегда плохо. Иногда даже что-то приходится специально замедлять (Digger помните? ну или общеизвестное "Быстро, качественно, дёшево - выберите два из трёх"). Нет в мире совершенства, всегда приходится чем-то жертвовать, и иногда это именно скорость.
А что именно тут плохо согласуется-то? По-моему, всё правильно и честно - цитаты вообще о разных вещах говорят, просто они, эти вещи, зависимы. Первая цитата предупреждает, что если нужна точность, то NUMERIC, а не FLOAT/DOUBLE, а вторая дополнительно сообщает, какова будет цена реализации этой требуемой точности.