Если же все будет дуть только внутрь, то мы получим горячий воздух внутри корпуса, которы не может нормально выйти из него, а следовательно система охлаждения толком работать не будет же.
Я говорю об обычных "бытовых" системах, и не рассматриваю экстремально разогретую игровую систему, где к тому же каждая стенка установлена с индивидуальной прокладкой. А так в большинстве корпусов щелей более чем достаточно, чтобы воздух свободно выходил без создания заметного избыточного давления. А вентилятор процессора обеспечивает такую интенсивность перемешивания в объёме корпуса, что направлением потоков можно в большинстве случаев пренебречь.
Не, если охлаждение в системе критично, то, конечно, не следует ТАК вмешиваться в потоки.
Да, опасность изопропанола действительно выше, чем ацетона или этанола. Ибо последние два являются естественными промежуточными продуктами метаболизма, чего про изпропанол не сказать.
Но опасность для электронных компонентов выше как раз у ацетона - многие изолирующие лаки в ацетоне растворимы (полностью или частично), а в изопропаноле нет.
А за попытку мыть плату этанолом в бытовых условиях могут и побить...
В строительных магазинах есть такая вещь как "обезжириватель универсальный"
Не надо. Кто знает, что там в составе? Порой состав вообще не указывается. К тому же зачастую там прямо на банке пишут "Не использовать в помещениях" - то есть в составе там имеется что-то не совсем для здоровья полезное. Вот оно надо? И вообще, системник, залитый машинным маслом - это редкость.
А изопропиловый спирт - вещество известное, достаточно безвредное и тыщу раз проверенное. Продаётся либо под своим именем, либо как "очиститель универсальный" - но обязательно проверять, что более ничего, кроме изопропанола, в составе нет. В отличие от обычного этилового спирта, тут лучше брать абсолютированный - бензола и иной дряни он не содержит.
Влажные салфетки - забыть как страшный сон! Они всегда смочены каким-то дерьмом, которое, конечно, хорошо для рук, но совершенно в никуда при очистке техники. Только изначально сухие салфетки, и обязательно из нетканого материала. А то находятся умельцы, которые трут бумажной салфеткой... или вынутой из-под блюдечка с кактусом.
Обязательный компонент, который должен быть у работника, занимающегося чисткой системника - изопропиловый спирт. Именно им смачиваем сухую салфетку, когда нужно что-то смыть.
Держать вентиляторы рукой - тоже не самое профессиональное занятие. Вентилятор блокируется от вращения либо отвёрткой, либо, если он хлипенький, то ватной палочкой. Кстати, ватные палочки - это тоже обязательная расходка.
Обязательно также наличие длинного нормально зажатого пинцета. И прежде чем дуть, большие клоки пыли и прочий консистентный мусор удаляется именно им. Иной раз между кулером и вентилятором собирается такой шматок войлока, что выдуть его совершенно нереально.
Блок питания для очистки - в обязательном порядке разбирать и очень тщательно чистить. Там налипшего и плохоудаляемого дерьма больше, чем в любом другом компоненте.
Кисть для очистки - должна быть с длинным, как минимум сантиметра 3-4, ворсом. При работе с ней продольных движений, тем более нажатий, быть не должно, если надо завести кисть в узкий зазор, это делается не прямыми, а колебательными движениями. Лучше брать кисть круглую (2 см) либо толстую плоскую (3х1см), натурального ворса, а если полимерную, то после каждой чистки мыть её с мылом, и после просушки обрабатывать антистатиком. Торчащие волоски - ровно срезать.
Ну и последнее. После очистки повернуть все вентиляторы так, чтобы они дули внутрь корпуса, и закрыть снаружи нетканой салфеткой в 2 слоя. Например, между корпусом и вентилятором, натянув салфетку, под винты, либо снаружи проклеить по контуру малярным скотчем. Тогда достаточно раз в месяц собрать пылесосом задержанную нетканкой пыль, а внутри системника даже через год чистота, словно его только что почистили. Исключение - один корпусной ставим на выдув. Обычно это вентилятор на морде системника под пластиком, ибо к нему просто так пылесосом не подлезть. Но надо обязательно проверить, что даже при такой конфигурации в корпусе создаётся подпор воздуха. Если не так - слишком мощный вентилятор, - лучше его вообще отключить.
А, да, влажные салфетки всё же должны быть с собой. Чтобы вытереть руки после работы.
Мда... ZIP на 125 кил с 3 файлами внутри сканировался 56 секунд. Причём DrWeb от участия в процессе вообще устранился. Могу себе представить, сколько будет сканироваться файл на 256 метров... даже если там внутри не будет какой-нить ZIP-бомбы.
Часто на собеседованиях спрашивают о таком параметре TCP как Window Size — размер окна. Речь про количество байт, которое вы можете отправить, не дожидаясь подтверждения.
Ну совершенно неоднозначная, а потому непонятная, фраза. Если узел А в заголовке пакета отправил узлу В значение Window = 1024, то попробуйте, опираясь на эту фразу, ответить, кто будет придерживаться этого ограничения при отправке - узел А, узел В или оба узла?
Объяснением вы конечно себя утруждать не хотите? "Вы меня поняли неправильно, а как правильно не скажу"?
Давайте обратимся к полной версии текста.
Любая бизнес-логика составлена из кучи элементарных операций. Сортировка, поиск, фильтрация, агрегация, расчёт, сравнение, выбор, и т.д., и т.п. И где-то есть та граница, после которой несколько последовательных элементарных операций становятся бизнес-логикой, специфической для конкретного процесса, хотя вот только что эта последовательность ещё была последовательностью достаточно стандартных операций, просто со специфическими константами, ограничениями и пр. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится.
Теперь посмотрим, что вы оставили при цитировании.
Любая бизнес-логика составлена из кучи элементарных операций. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится
Итак, в исходном тексте утверждается, что есть та граница детализации, ниже которой элементарная операция или последовательность таких операций ещё не составляет элемента бизнес-логики, а является стандартной обработкой набора данных. И если такую последовательность выполнять не как набор отдельных операций, а единую агрегированную операцию, то она по-прежнему не станет элементом бизнес-логики.
А что оставили вы? Вы оставили часть текста, которая утверждает, что агрегировать можно без оглядки на такую границу.
Вы же говорили про перенос бизнес-логики в хранимую процедуру:"Любая бизнес-логика составлена из кучи элементарных операций. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится".
Нет, я ожидал неприятия и непонимания, а потому ваши возражения мне неудивительны. Но вот таких передёргиваний - выбросить кусок текста из середины так, чтобы смысл оставшегося инвертировался, и на основании полученной цитаты, заведомо не имеющей отношения к оригиналу, убеждать меня в ошибочности моего мнения,- не ожидал.
У бизнеса вообще нет такой операции "Добавить доставку в корзину", в корзину можно добавлять только товары и коды скидок.
Цитирую ваши слова: "Есть бизнес-требование "Если есть товары из группы А, добавить дополнительную строку доставки 1000 рублей, потому что требуется грузчик". Его реализация это бизнес-логика." То есть требование есть, логика есть а операции нет? Хотя строка "Доставка" финально-таки есть. Непонятно.
Есть процедура "Создание заказа". Она вызывается только с id корзины, где есть список товаров. Есть бизнес-требование "Если есть товары из группы А, добавить дополнительную строку доставки 1000 рублей, потому что требуется грузчик". Его реализация это бизнес-логика. Вы это регулируете параметрами процедуры или if в коде процедуры?
Я добавлю эту дополнительную строку в список товаров корзины ПЕРЕД вызовом процедуры.
Процедура должна выполнять именно операцию создания заказа по переданному ей списку товаров с количествами и вернуть результаты своей работы (номер созданного заказа либо признак/код ошибки создания заказа). Это элементарная операция за пределами бизнес-логики. Добавление же строки - это бизнес-логика, которая реализуется в коде приложения, либо до вызова процедуры добавлением нужной строки в состав корзины (в процессе создания корзины в момент добавления в неё товара группы А, либо в момент финализации создания корзины и перехода к созданию заказа), либо после неё получением характеристик созданного заказа и вызовом процедуры корректировки заказа.
С кодом в приложении такого документирования требуется заметно меньше,
Вот этого не понимаю от слова "совсем". Есть "число 42". В документировании должна быть добавлена строка, которая разъясняет, что это за значение, куда и в каком случае пишется и т.п. Объясните мне, почему эта строка в документировании приложения будет короче. чем в документировании процедуры...
Или вы хотите сказать, что в процедуре это задокументировать нужно, а в приложении нет? Ну тогда мы снова возвращаемся к тому, что новый сотрудник дока в используемом ЯП (и так знает, что это за "42") и ноль в SQL.
какая-то процедура пишет в какую-то таблицу число 42, которое неизвестно что обозначает, и неизвестно кто его читает.
Ну то есть вся проблема - в хреновом документировании, что ли?
Процедура реализует правила и ограничения бизнеса - это бизнес-логика.
Вот только не надо тёплое да мягкое в одну кучу, да... Процедура реализует правила и ограничения, которые передаются в неё значениями параметров. Всё. Точка.
А вызов этой процедуры передаваемыми параметрами задаёт используемые ограничения и параметры применения правил в соответствии с требованиями бизнеса - вот сам вызов и есть бизнес-логика. Но он не на SQL сервере. а в вашем бизнес-приложении.
Вот если вы и параметры, необходимые бизнес-процессу, захардкодили в процедуре, то да, она как-то уже стала не общей процедурой, а куском вашей бизнес-логики. Но кто в том виноват-то?
Это связано с тем, что требования к качеству работы приложений возросли, а новых инструментов в SQL для решения этой проблемы так и не появилось, что не позволило повысить качество.
Невозможно относиться к подобным сентенциям иначе, чем к древнему "Кому сейчас нужна командная строка, если всё можно сделать мышкой". Инструмента, видите ли, нету...
Со временем, когда отцы-основатели данной хранимой процедуры покидают компанию, вместе с ними уходит и понимание того, как всё это должно функционировать. Новым сотрудникам, чтобы внести небольшие изменения, приходится собирать информацию по крупицам от тех, кто хоть как-то взаимодействовал с этим чудом инженерной мысли.
Переводя на русский - программист с хорошим знанием SQL уволился, а вместо него наняли другого, который в SQL ни ухом, ни рылом.
А виновата, как обычно, хранимая процедура.
Размазанность бизнес логики
Вот интересно, вас использование в бизнес-логике различных функций и процедур из "стандартных" библиотек не раскорячивает? Или если процедура поставляется с ОС/фреймворком/средой/прочее - то это built-in, а если сам написАл - то это бизнес-логика?
Любая бизнес-логика составлена из кучи элементарных операций. Сортировка, поиск, фильтрация, агрегация, расчёт, сравнение, выбор, и т.д., и т.п. И где-то есть та граница, после которой несколько последовательных элементарных операций становятся бизнес-логикой, специфической для конкретного процесса, хотя вот только что эта последовательность ещё была последовательностью достаточно стандартных операций, просто со специфическими константами, ограничениями и пр. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится. Просто отлаживать надо лучше, условий учитывать больше, входные проверять жёстче, документировать качественнее. Должно быть - "написал и забыл".
А SQL-сервер обрабатывает данные всяко лучше, чем программист напишет.
Одна крайность - просто сайт со списком мошеннических телефонных номеров и адресами фишинговых сайтов.
Другая крайность - все звонки и доступ в инет через их шлюзы, с авторизацией через госуслуги.
А вот вменяемой серединки-то я как-то не вижу... во всяком случае той, которую реально создать. Особенно если ещё захотеть, чтобы БР и прочие ФО компенсировали, случись что.
Так много слов, и практически ничего по делу. Считай, одна вода. А местами так и вовсе неверная информация. Например:
когда вы отправляете сообщение через Интернет, маршрутизаторы определяют оптимальный путь для передачи вашего сообщения от вашего компьютера до сервера получателя.
Да вот ни разу! Маршрутизатор никакие пути не строит и не сравнивает. В лучшем случае маршрутизатор определит, какой следующий узел, по его мнению, будет оптимален для передачи, и именно туда отправит пакет... а как путь этого пакета сложится дальше, ему глубоко пофиг.
Я говорю об обычных "бытовых" системах, и не рассматриваю экстремально разогретую игровую систему, где к тому же каждая стенка установлена с индивидуальной прокладкой. А так в большинстве корпусов щелей более чем достаточно, чтобы воздух свободно выходил без создания заметного избыточного давления. А вентилятор процессора обеспечивает такую интенсивность перемешивания в объёме корпуса, что направлением потоков можно в большинстве случаев пренебречь.
Не, если охлаждение в системе критично, то, конечно, не следует ТАК вмешиваться в потоки.
Да, опасность изопропанола действительно выше, чем ацетона или этанола. Ибо последние два являются естественными промежуточными продуктами метаболизма, чего про изпропанол не сказать.
Но опасность для электронных компонентов выше как раз у ацетона - многие изолирующие лаки в ацетоне растворимы (полностью или частично), а в изопропаноле нет.
А за попытку мыть плату этанолом в бытовых условиях могут и побить...
Не надо. Кто знает, что там в составе? Порой состав вообще не указывается. К тому же зачастую там прямо на банке пишут "Не использовать в помещениях" - то есть в составе там имеется что-то не совсем для здоровья полезное. Вот оно надо? И вообще, системник, залитый машинным маслом - это редкость.
А изопропиловый спирт - вещество известное, достаточно безвредное и тыщу раз проверенное. Продаётся либо под своим именем, либо как "очиститель универсальный" - но обязательно проверять, что более ничего, кроме изопропанола, в составе нет. В отличие от обычного этилового спирта, тут лучше брать абсолютированный - бензола и иной дряни он не содержит.
Влажные салфетки - забыть как страшный сон! Они всегда смочены каким-то дерьмом, которое, конечно, хорошо для рук, но совершенно в никуда при очистке техники. Только изначально сухие салфетки, и обязательно из нетканого материала. А то находятся умельцы, которые трут бумажной салфеткой... или вынутой из-под блюдечка с кактусом.
Обязательный компонент, который должен быть у работника, занимающегося чисткой системника - изопропиловый спирт. Именно им смачиваем сухую салфетку, когда нужно что-то смыть.
Держать вентиляторы рукой - тоже не самое профессиональное занятие. Вентилятор блокируется от вращения либо отвёрткой, либо, если он хлипенький, то ватной палочкой. Кстати, ватные палочки - это тоже обязательная расходка.
Обязательно также наличие длинного нормально зажатого пинцета. И прежде чем дуть, большие клоки пыли и прочий консистентный мусор удаляется именно им. Иной раз между кулером и вентилятором собирается такой шматок войлока, что выдуть его совершенно нереально.
Блок питания для очистки - в обязательном порядке разбирать и очень тщательно чистить. Там налипшего и плохоудаляемого дерьма больше, чем в любом другом компоненте.
Кисть для очистки - должна быть с длинным, как минимум сантиметра 3-4, ворсом. При работе с ней продольных движений, тем более нажатий, быть не должно, если надо завести кисть в узкий зазор, это делается не прямыми, а колебательными движениями. Лучше брать кисть круглую (2 см) либо толстую плоскую (3х1см), натурального ворса, а если полимерную, то после каждой чистки мыть её с мылом, и после просушки обрабатывать антистатиком. Торчащие волоски - ровно срезать.
Ну и последнее. После очистки повернуть все вентиляторы так, чтобы они дули внутрь корпуса, и закрыть снаружи нетканой салфеткой в 2 слоя. Например, между корпусом и вентилятором, натянув салфетку, под винты, либо снаружи проклеить по контуру малярным скотчем. Тогда достаточно раз в месяц собрать пылесосом задержанную нетканкой пыль, а внутри системника даже через год чистота, словно его только что почистили. Исключение - один корпусной ставим на выдув. Обычно это вентилятор на морде системника под пластиком, ибо к нему просто так пылесосом не подлезть. Но надо обязательно проверить, что даже при такой конфигурации в корпусе создаётся подпор воздуха. Если не так - слишком мощный вентилятор, - лучше его вообще отключить.
А, да, влажные салфетки всё же должны быть с собой. Чтобы вытереть руки после работы.
Так всё же разъясните непонятку с горяче-холодным шоколадом... судя по тому, что в вашем решении это не учитывается, задача допускает этот бред?
Мда... ZIP на 125 кил с 3 файлами внутри сканировался 56 секунд. Причём DrWeb от участия в процессе вообще устранился. Могу себе представить, сколько будет сканироваться файл на 256 метров... даже если там внутри не будет какой-нить ZIP-бомбы.
Не нашёл, признаться, ничего интересного. Тупой подсчёт количества вариантов, суммирование, и отсчёт заданного количества дней от текущей (?) даты.
Да, порадовал горячий шоколад, который теперь можно сделать не только горячим, но и холодным.
Вот и я о том же - надо писать полностью и точно. Или уж лучше вообще ничего на этот счёт не писать.
Ну совершенно неоднозначная, а потому непонятная, фраза. Если узел А в заголовке пакета отправил узлу В значение Window = 1024, то попробуйте, опираясь на эту фразу, ответить, кто будет придерживаться этого ограничения при отправке - узел А, узел В или оба узла?
Давайте обратимся к полной версии текста.
Теперь посмотрим, что вы оставили при цитировании.
Итак, в исходном тексте утверждается, что есть та граница детализации, ниже которой элементарная операция или последовательность таких операций ещё не составляет элемента бизнес-логики, а является стандартной обработкой набора данных. И если такую последовательность выполнять не как набор отдельных операций, а единую агрегированную операцию, то она по-прежнему не станет элементом бизнес-логики.
А что оставили вы? Вы оставили часть текста, которая утверждает, что агрегировать можно без оглядки на такую границу.
Нет, я ожидал неприятия и непонимания, а потому ваши возражения мне неудивительны. Но вот таких передёргиваний - выбросить кусок текста из середины так, чтобы смысл оставшегося инвертировался, и на основании полученной цитаты, заведомо не имеющей отношения к оригиналу, убеждать меня в ошибочности моего мнения,- не ожидал.
Цитирую ваши слова: "Есть бизнес-требование "Если есть товары из группы А, добавить дополнительную строку доставки 1000 рублей, потому что требуется грузчик". Его реализация это бизнес-логика." То есть требование есть, логика есть а операции нет? Хотя строка "Доставка" финально-таки есть. Непонятно.
Вроде 7 часов назад это всё было опубликовано как пост...
Я добавлю эту дополнительную строку в список товаров корзины ПЕРЕД вызовом процедуры.
Процедура должна выполнять именно операцию создания заказа по переданному ей списку товаров с количествами и вернуть результаты своей работы (номер созданного заказа либо признак/код ошибки создания заказа). Это элементарная операция за пределами бизнес-логики. Добавление же строки - это бизнес-логика, которая реализуется в коде приложения, либо до вызова процедуры добавлением нужной строки в состав корзины (в процессе создания корзины в момент добавления в неё товара группы А, либо в момент финализации создания корзины и перехода к созданию заказа), либо после неё получением характеристик созданного заказа и вызовом процедуры корректировки заказа.
Вот этого не понимаю от слова "совсем". Есть "число 42". В документировании должна быть добавлена строка, которая разъясняет, что это за значение, куда и в каком случае пишется и т.п. Объясните мне, почему эта строка в документировании приложения будет короче. чем в документировании процедуры...
Или вы хотите сказать, что в процедуре это задокументировать нужно, а в приложении нет? Ну тогда мы снова возвращаемся к тому, что новый сотрудник дока в используемом ЯП (и так знает, что это за "42") и ноль в SQL.
Ну то есть вся проблема - в хреновом документировании, что ли?
Вот только не надо тёплое да мягкое в одну кучу, да... Процедура реализует правила и ограничения, которые передаются в неё значениями параметров. Всё. Точка.
А вызов этой процедуры передаваемыми параметрами задаёт используемые ограничения и параметры применения правил в соответствии с требованиями бизнеса - вот сам вызов и есть бизнес-логика. Но он не на SQL сервере. а в вашем бизнес-приложении.
Вот если вы и параметры, необходимые бизнес-процессу, захардкодили в процедуре, то да, она как-то уже стала не общей процедурой, а куском вашей бизнес-логики. Но кто в том виноват-то?
Да, обязательно. Это составная часть контроля входных данных. Переданные координаты не должны выходить за границы.
Невозможно относиться к подобным сентенциям иначе, чем к древнему "Кому сейчас нужна командная строка, если всё можно сделать мышкой". Инструмента, видите ли, нету...
Переводя на русский - программист с хорошим знанием SQL уволился, а вместо него наняли другого, который в SQL ни ухом, ни рылом.
А виновата, как обычно, хранимая процедура.
Вот интересно, вас использование в бизнес-логике различных функций и процедур из "стандартных" библиотек не раскорячивает? Или если процедура поставляется с ОС/фреймворком/средой/прочее - то это built-in, а если сам написАл - то это бизнес-логика?
Любая бизнес-логика составлена из кучи элементарных операций. Сортировка, поиск, фильтрация, агрегация, расчёт, сравнение, выбор, и т.д., и т.п. И где-то есть та граница, после которой несколько последовательных элементарных операций становятся бизнес-логикой, специфической для конкретного процесса, хотя вот только что эта последовательность ещё была последовательностью достаточно стандартных операций, просто со специфическими константами, ограничениями и пр. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится. Просто отлаживать надо лучше, условий учитывать больше, входные проверять жёстче, документировать качественнее. Должно быть - "написал и забыл".
А SQL-сервер обрабатывает данные всяко лучше, чем программист напишет.
Логической-то может и нет, а вот идеологическая присутствует.
Любой ввод должен быть проверен. Особенно интерактивный.
Одна крайность - просто сайт со списком мошеннических телефонных номеров и адресами фишинговых сайтов.
Другая крайность - все звонки и доступ в инет через их шлюзы, с авторизацией через госуслуги.
А вот вменяемой серединки-то я как-то не вижу... во всяком случае той, которую реально создать. Особенно если ещё захотеть, чтобы БР и прочие ФО компенсировали, случись что.
Знаю только четверть. Убеждён, что лично мне из всех этих сайтов нужны .. чуть меньше чем один.
Пожалуй, присоединюсь к Вашему счастливому неведению...
Так много слов, и практически ничего по делу. Считай, одна вода. А местами так и вовсе неверная информация. Например:
Да вот ни разу! Маршрутизатор никакие пути не строит и не сравнивает. В лучшем случае маршрутизатор определит, какой следующий узел, по его мнению, будет оптимален для передачи, и именно туда отправит пакет... а как путь этого пакета сложится дальше, ему глубоко пофиг.