Какая польза верхнему уровню, вплоть до живого человека, знать, что где-то там глубоко внизу случился DNS lookup failure по причине того, что timeout? Что этот самый верхний уровень должен с этой информацией делать?
Верхнему уровню, по большому счету, надо знать:
1) можно ли сделать что-то, в терминах API, который вернул ошибку, чтобы ошибка рассосалась? Ну, например, подождать (сколько?) и попробовать еще раз, предоставить дополнительную информацию (какую?), и т.п.
2) не вызвана ли ошибка неверными параметрами?
3) что сказать человеку, если нужно его вмешательство?
4) что записать в лог для разработчика?
Важность достижимости скорости исполнения, близкой к аппаратной, сильно переоценена.
За редким исключением, узким местом является не кодогенерация, а способность человека понимать исходный (не машинный) код и адекватным образом с ним управляться. Это приводит ко многим негативным последствиям, одним из которых (не самым важным) является написание медленного кода. Т.е., каждый конкретный маленький кусочек исполняется быстро, но все вместе работает медленно, потому, что человек, погрязший в общей сложности проекта, выбирает неоптимальную архитектуру, неопримальные структуры данных и неоптимальные алгоритмы.
Разница между overhead'ом в 1% и 5% вообще малосущественна, потому что это разница между скоростью 99% и 95% — под микроскопом не различишь.
С другой стороны, исключения, как способ работать с ошибками, имеет существенные недостатки, именно с точки зрения организации исходного кода. Один из них — разрыв «сюжетной линии» программы между кодом, который что-то делает, и кодом, который разгребает последствия. Получается, что при ошибке программа вылетает неведомо куда, и это место находится по тексту далеко от того места, где возникла ошибка. Другая проблема — исключения с легкостью пролетают между уровнями абстракции, и что, простите, высокоуровневый код, работающий с базой данных, должен делать с исключениями, прилетевшими из низкоуровнего кода, работающего с сетевым стеком, если он ничего про сеть не знает (ну, по крайней мере, не должен знать)? Третья проблема — обработка «внешних» ошибок (файл не открылся, данные испорчены, блок на диск не записался) должна кардинально отличаться от обработки ошибок во внутренней логике программы (это ошибки программиста, а не условий, в которых оказался исполняемый код), систематическое использование исключений помогает с легкостью смешивать эти совершенно разные вещи между собой.
Обработка ошибок — вообще очень сложная тема, и многие программы с ней не справляются даже на уровне «написать осмысленное сообщение в лог и завершиться, по возможности ничего не сломав». Поэтому говорить о механизме обработки ошибок гораздо интереснее с точки зрения, как этот механизм помогает сделать обработку корректной, не переусложная чрезмерно логику программы, а не с точки зрения, как он позволяет ускорить ее исполнение на 4%.
Это тот самый случай, про который сказано, premature optimization is the root of all evil.
Не очень понятно, что такое время, уделенное вопросам безопасности.
Например, если я прилагаю изрядные усилия для обеспечения общей корректности кода, включая, но не ограничиваясь, усилиями по корректной работе с памятью, это время уделено вопросам безопасности или не им?
Или надо специально напрячь нужную морщину на лбу, и сказать всем, «сейчас я работаю с вопросами безопасности», и именно это время засчитывается?
У Go есть 2 компилятора, «родной» и на основе gcc. Тот, который на основе gcc представляет пока что лишь академический интерес. Мало того, что он очень медленный, он еще и код во многих случаях генерирует хуже, хоть у него и gcc внутри.
И еще добавлю пару-тройку малоизвестных вещей про встроенный фаирвол. Правда, я довольно давно проверял, где-то на уровне семерки. Возможно, с тех пор что-то изменилось.
Первое. Когда программа открывает порт для входящих соединений, и на экране появляется диалог с вопросом, разрешать или нет, все то время, пока этот диалог висит не отвеченный, порт реально открыт. Закрывается он в тот момент, когда пользователь говорит, «порт не открывать». Вероятно это сделано из соображений, что за то время, пока пользователь думает, злобный хакер много вреда нанести не успеет, а вот если сразу сделать порт закрытым, наивная программа может и сломаться.
Второе. Если программа является сервисом, никакого диалога не появится, система сама примет решение «порт не открывать». Но вот только на обдумывание этого решения у нее уйдет несколько секунд. Выглядит это так: создали слушающий сокет, к нему кто-то приконнектился, данные полетели, а через несколько секунд вдруг неожиданно перестали. Когда с этим сталкиваешься первый раз, отладка занимает некоторое время.
Третье. Если программа говорит bind(), указав нулевой номер порта (т.е., пускай система сама назначит порт автоматически), никакого диалога от фаирвола не появляется, и порт по умолчанию будет открыт. Видимо считается, что поскольку номер порта выделяется более-менее случайно, злобный хакер ни в жизнь его не угадает.
Это не корректный подсчет. На самом деле, надо бы как-то оценить энергию импульса, приходящуюся именно на свариваемую зону, а для этого не хватает понимания о величине падения напряжения на ней
У меня в молодости был роскошный советский конденсатор на 10000 мкф, и при заряде до 12 в и коротком замыкании отверткой или чем-нибудь подобным он испускал отличный сноп искр, и достаточно крепко приваривал к себе то, чем делалось короткое замыкание. И ничего с ним не было от такого обращения.
Ток пульсаций протекают через конденсатор продолжительное время, и тепло успевает накапливаться. А тут, короткий импульс, и потом, пока в следующий раз целишься, у конденсатора полно времени, чтобы остыть
В общем, я бы попробовал. Благо цена вопроса копеешная, и в форме материальных затрат, и в форме времени, потраченного на эксперименты
Дозировать энергию импульса легко можно, меняя напряжение, до которого заряжен конденсатор
Что до формы импульса, если большая часть энергии выделяется за время, за которое теплопроводность свариваемого металла не успеет «утащить» существенную энергию, то в первом приближении, казалось бы, на форму наплевать
0.12 Ф — это 120000 мкф, так что я почти угадал :-)
На самом деле, в изначальной статье непонятно, сколько энергии выделяется непосредственно в зоне сварки, а сколько рассеивается в проводах, включая обмотку трансформатора
Что-то мне подсказывает, что если взять электролитический конденсатор микрофарад на 50000-100000, зарядить его вольт до 20 и разрядить на сварочные электроды, плотно прижатые к привариваемой ленте, то получится примерно то, что надо, и без всякой Ардуины.
Верхнему уровню, по большому счету, надо знать:
1) можно ли сделать что-то, в терминах API, который вернул ошибку, чтобы ошибка рассосалась? Ну, например, подождать (сколько?) и попробовать еще раз, предоставить дополнительную информацию (какую?), и т.п.
2) не вызвана ли ошибка неверными параметрами?
3) что сказать человеку, если нужно его вмешательство?
4) что записать в лог для разработчика?
За редким исключением, узким местом является не кодогенерация, а способность человека понимать исходный (не машинный) код и адекватным образом с ним управляться. Это приводит ко многим негативным последствиям, одним из которых (не самым важным) является написание медленного кода. Т.е., каждый конкретный маленький кусочек исполняется быстро, но все вместе работает медленно, потому, что человек, погрязший в общей сложности проекта, выбирает неоптимальную архитектуру, неопримальные структуры данных и неоптимальные алгоритмы.
Разница между overhead'ом в 1% и 5% вообще малосущественна, потому что это разница между скоростью 99% и 95% — под микроскопом не различишь.
С другой стороны, исключения, как способ работать с ошибками, имеет существенные недостатки, именно с точки зрения организации исходного кода. Один из них — разрыв «сюжетной линии» программы между кодом, который что-то делает, и кодом, который разгребает последствия. Получается, что при ошибке программа вылетает неведомо куда, и это место находится по тексту далеко от того места, где возникла ошибка. Другая проблема — исключения с легкостью пролетают между уровнями абстракции, и что, простите, высокоуровневый код, работающий с базой данных, должен делать с исключениями, прилетевшими из низкоуровнего кода, работающего с сетевым стеком, если он ничего про сеть не знает (ну, по крайней мере, не должен знать)? Третья проблема — обработка «внешних» ошибок (файл не открылся, данные испорчены, блок на диск не записался) должна кардинально отличаться от обработки ошибок во внутренней логике программы (это ошибки программиста, а не условий, в которых оказался исполняемый код), систематическое использование исключений помогает с легкостью смешивать эти совершенно разные вещи между собой.
Обработка ошибок — вообще очень сложная тема, и многие программы с ней не справляются даже на уровне «написать осмысленное сообщение в лог и завершиться, по возможности ничего не сломав». Поэтому говорить о механизме обработки ошибок гораздо интереснее с точки зрения, как этот механизм помогает сделать обработку корректной, не переусложная чрезмерно логику программы, а не с точки зрения, как он позволяет ускорить ее исполнение на 4%.
Это тот самый случай, про который сказано, premature optimization is the root of all evil.
Например, если я прилагаю изрядные усилия для обеспечения общей корректности кода, включая, но не ограничиваясь, усилиями по корректной работе с памятью, это время уделено вопросам безопасности или не им?
Или надо специально напрячь нужную морщину на лбу, и сказать всем, «сейчас я работаю с вопросами безопасности», и именно это время засчитывается?
У Go есть 2 компилятора, «родной» и на основе gcc. Тот, который на основе gcc представляет пока что лишь академический интерес. Мало того, что он очень медленный, он еще и код во многих случаях генерирует хуже, хоть у него и gcc внутри.
Такой вот у нас в C isalnum. Понять это нельзя, это можно только запомнить.
> Уходим на ребут и все! Вы невероятны и с собственным почтовым сервером!
И удивляемся, почему все отправленные нами письма ложатся у получателей в spam
В общем. тема DKIM, SPF, DMARC не раскрыта
www.dmarcanalyzer.com/dkim
www.dmarcanalyzer.com/spf
Первое. Когда программа открывает порт для входящих соединений, и на экране появляется диалог с вопросом, разрешать или нет, все то время, пока этот диалог висит не отвеченный, порт реально открыт. Закрывается он в тот момент, когда пользователь говорит, «порт не открывать». Вероятно это сделано из соображений, что за то время, пока пользователь думает, злобный хакер много вреда нанести не успеет, а вот если сразу сделать порт закрытым, наивная программа может и сломаться.
Второе. Если программа является сервисом, никакого диалога не появится, система сама примет решение «порт не открывать». Но вот только на обдумывание этого решения у нее уйдет несколько секунд. Выглядит это так: создали слушающий сокет, к нему кто-то приконнектился, данные полетели, а через несколько секунд вдруг неожиданно перестали. Когда с этим сталкиваешься первый раз, отладка занимает некоторое время.
Третье. Если программа говорит bind(), указав нулевой номер порта (т.е., пускай система сама назначит порт автоматически), никакого диалога от фаирвола не появляется, и порт по умолчанию будет открыт. Видимо считается, что поскольку номер порта выделяется более-менее случайно, злобный хакер ни в жизнь его не угадает.
Я бы подключил конденсатор через силовой тиристор, прижимал бы руками с усилием, а потом уже отпирал тиристор (вероятно, ногой, руки-то заняты).
Ток пульсаций протекают через конденсатор продолжительное время, и тепло успевает накапливаться. А тут, короткий импульс, и потом, пока в следующий раз целишься, у конденсатора полно времени, чтобы остыть
В общем, я бы попробовал. Благо цена вопроса копеешная, и в форме материальных затрат, и в форме времени, потраченного на эксперименты
Что до формы импульса, если большая часть энергии выделяется за время, за которое теплопроводность свариваемого металла не успеет «утащить» существенную энергию, то в первом приближении, казалось бы, на форму наплевать
На самом деле, в изначальной статье непонятно, сколько энергии выделяется непосредственно в зоне сварки, а сколько рассеивается в проводах, включая обмотку трансформатора
Энергию импульса, очевидно, можно регулировать, изменяя напряжение, до которого заряжается конденсатор.