Почему с фабрики надо брать налог, а с майнеров нет?
С моей точки зрения майнеры не добывают рубли. Они считают числа и получают за это тоже числа - коины. Разве электронные коины в России - это деньги? Насколько я знаю в России на них ничего не купить - я не могу пойти и купить, например, монитор за коины в том же, например, ДНС. Ну так с чего надо с их «добычи» платить какой-то налог?
Или ни с кого не брать и государство распустить?
Так а в чём функция государства? Только налоги собирать? Или всё-таки государство что-то должно на эти налоги сделать и отчитаться о проделанной работе для людей? Вы бы не подменяли понятия - не государство распустить, а на 90% чиновничий и силовой аппарат, которые только потребляют и ничего не производят, а оказываемые ими услуги в большинстве своём отрицательного качества.
Вот в этом-то и проблема, что налоги собираются, но граждане их не платят! Граждане даже не видят, сколько денег с них собирает правительство. Большинство граждан что-то слышали про странную цифру в 13% и при этом скорее ощущают это как оброк (вроде как и не очень жалко, можно потерпеть). Про всякие отчисления свыше 13% слышали уже гораздо меньше. Вот если бы граждане платили бы самостоятельно все эти налоги (откладывая их из своей кровной ЗП, чтобы потом расстаться с этой суммой на самом деле, а не автоматически), то они бы видели, сколько реально было собрано денег и сколько они получили услуг на эти деньги. Может быть тогда бы что-то сошлось у них в голове. Но правительство усиленно работает над тем, чтобы граждане оставались в неведении, сколько реально отчисляются налогов, чтобы и дальше продолжать их спокойно обирать собирать.
Спасибо за "заботу". Вот так разговариваешь, разговариваешь, а тут выясняется, что тебя никто и не слушает, связь давно отключена. Хоть бы спрашивали, например: "хотите продолжить разговор, нажмите 1", чтобы было понятно что происходит, а то взяли привычку просто по английски отключать. Очень "приятно"! Особенно доставляет, когда организация, на которую почти невозможно повлять вдруг "вспоминает": "О, да у меня же есть пользователи! Ну-ка, позабочусь-ка я о них!"
смогут оценивать работников по их результативности, тогда как у работников сохраняется стимул минимизировать время их выполнения
Такого работодателя ещё поискать. Обычно всё банальней - вместо повышения зарплаты повышают... норму. Поэтому эти сказки про более лучший способ "оценки" эффективности надо оставить совсем уж доверчивым сотрудникам.
Всегда интересуюсь в таких случаях, а «кто такие мы?» Почему продаем газ мы, а прибыль и сверхдоходы у кого-то одного, в Лондоне, а у меня только зарплата? /S
P.S.
Кстати, по поводу «свалить»: свалили ведь и олигархи тоже, точнее они не возвращались.
"Относись к другим так же, как ты хочешь, чтобы относились к тебе."
По моему это узкое правило нельзя применять в широком смысле. Сразу давать безлимитный кредит доверия незнакомому человеку - так себе идея. Скорее это больше относится к узкому кругу близких знакомых и друзей, с которыми регулярно общаешься и взаимодействуешь и у тебя есть возможность возврата таких моральных долгов. Остальным ещё надо заслужить такое отношение к ним.
Использование одного UserInputException с этой точки зрения противоречит этому, потому что когда разработчик читает код без текста ошибки
Так я же не говорил, что задача использовать только одно исключение. Можено, но это не обязательно. Я предлагал пронумеровать все сообщения, которые куда-либо записываются или выводятся.
Код ошибки и traceId совершенно для разных целей
Так я вот как раз и против такого использования. С моей точки зрения число должно быть одно и оно должно вести к строке исходного кода, где возникла проблемная ситуация - исключение или просто предупреждение (потому что пользователь может быть не согласен с предупреждением и либо надо где-то к номеру привязать более корректное описание или доработать систему). Конечно, в сообщении, которое отображается пользователю могут быть указаны ещё параметры, например, номер транзакции, который сам по себе уникален (и любые другие параметры, которые могут указывать на какой-то бизнес-контекст), но изначально ошибка генерируется в определённом месте программы и нужны её точные "координаты". Это может быть только число (или уникальная строка, но числа всё-таки проще читать и проверять на уникальность, чем рандомные строки).
Или если внутри системы вылетел какой-то неожиданный Exception - мы обрабатываем его через общий ExceptionHandler и логируем. Пользователю отвечаем технической ошибкой (у нас что-то сломалось) и traceId.
Честно, я до сих пор не понимаю - traceId он вообще ведёт к точному месту в исходном коде, где возникла ошибка или нет? Или он ведёт к записи в логах и только там можно прочитать внутренние сообщения об ошибках? (но тогда не ясно - а эти сообщения об ошибках точно и однозначно ведут с конкретной строке исходного кода?) Понимаете, я хочу построить однозначный и прозрачный алгоритм сопоставления какого либо/любого сообщения, генерируемого системой (исключение, предупреждение, запись в логи) с конкретной строкой исходного кода, где это сообщение возникло, чтобы любой человек с доступом к исходному коду мог за пару секунд найти эту строку в программе, а только потом разбираться в контексте, что там с бизнес-логикой. TraceId позволяет это сделать? (я надеюсь, что формулировку задачи я выразил полностью?)
P.S.
Я тоже логирую Stacktrace, но его не так просто читать, особенно, когда сообщения об ошибках всплывают из глубины системных библиотек.
P.P.S.
Вот что меня смущает в stacktrace - версионность исходных кодов программы. Как только вы внесёте изменения в программу, то stacktrace становится невалидным и все сообщения, даже имеющие traceid, становятся бесполезными.
Кстати, можно ещё обратить внимание на способ удаления воздуха из корпуса. Т.е. водянка неплохо, но удаление нагретого воздуха - это тоже задача, поэтому без воздушных вентиляторов всё равно не обойтись. А т.к. много тепловыделения идёт на видеокарте, то и, неожиданно, но именно она может самостоятельно заниматься отводом тепла, например, серия (RTX 3080 Turbo), которая самостоятельно удаляет своё тепло из корпуса, а не просто разбрасывает тепло по корпусу огромными вентиляторами, мешая всем.
Я понял что не написал с самого начала. Речь вообще про сообщения при взаимодействии пользователя с сервером, а не только Exception. Сообщения от сервера могут быть очень разнообразными, поэтому я и предлагаю их нумеровать не зависимо от того - это сообщение от исключения или от сообщения от бизнес-правила.
Т.е. у вас UserInputException("E111. Текст1") должно быть одно. Т.е. все сообщения, которые куда-то должны вернуться должны иметь уникальные идентификаторы прямо в тексте: UserInputException("E112. Текст2") /UserInputException("E113. Текст3")/return "E114. Текст4."/Log.Add("E115. Транзакция {NNN} прошла успешно."). Т.е. вообще любое взаимодействие с пользователем, возврат простого сообщения, запись в журнал лога нумеруется уникальным числом и поясняется текстом. Просто сообщения всех устраивают, а уникальные числа в сообщениях почему-то вызывают дискомфорт?
Если так можно выразиться - провести unicalization сообщений. Тогда общение пользователей с техподдержкой и техподдержки с разработчиками становится прозрачным.
Я неоднократно встречался с тем, что получаю сообщение об ошибке в какой-то утилите с исходным кодом, идешь в исходный код, находишь там шаблон этого сообщения и он там встречается 10 раз. Вот какое место в программе выдало моё сообщение об ошибке, когда текстовые шаблоны сообщений одинаковые? - Это уже риторический вопрос, потому что дальше только отладка.
А это точно мысль со здравым смыслом? Не объясните, зачем регистрировать «мощности» в госорганах?
С моей точки зрения майнеры не добывают рубли. Они считают числа и получают за это тоже числа - коины. Разве электронные коины в России - это деньги? Насколько я знаю в России на них ничего не купить - я не могу пойти и купить, например, монитор за коины в том же, например, ДНС. Ну так с чего надо с их «добычи» платить какой-то налог?
Так а в чём функция государства? Только налоги собирать? Или всё-таки государство что-то должно на эти налоги сделать и отчитаться о проделанной работе для людей? Вы бы не подменяли понятия - не государство распустить, а на 90% чиновничий и силовой аппарат, которые только потребляют и ничего не производят, а оказываемые ими услуги в большинстве своём отрицательного качества.
Вот в этом-то и проблема, что налоги собираются, но граждане их не платят! Граждане даже не видят, сколько денег с них собирает правительство. Большинство граждан что-то слышали про странную цифру в 13% и при этом скорее ощущают это как оброк (вроде как и не очень жалко, можно потерпеть). Про всякие отчисления свыше 13% слышали уже гораздо меньше. Вот если бы граждане платили бы самостоятельно все эти налоги (откладывая их из своей кровной ЗП, чтобы потом расстаться с этой суммой на самом деле, а не автоматически), то они бы видели, сколько реально было собрано денег и сколько они получили услуг на эти деньги. Может быть тогда бы что-то сошлось у них в голове. Но правительство усиленно работает над тем, чтобы граждане оставались в неведении, сколько реально отчисляются налогов, чтобы и дальше продолжать их спокойно
обиратьсобирать.На деревню дедушке. Чтобы попасть в тестируемую группу надо сначала родиться кроликом:
Эта новость из разряда «ученый изнасиловал журналиста». В данном случае автор новости написал кликбейтный заголовок.
Судя по всему книги - не основном потребитель древесины, особенно в 2022 году. Обратите внимание, кто занимается вырубкой леса:
Первый раз о таком слышу. Не удивлюсь, если это платная услуга. )))
Спасибо за "заботу". Вот так разговариваешь, разговариваешь, а тут выясняется, что тебя никто и не слушает, связь давно отключена. Хоть бы спрашивали, например: "хотите продолжить разговор, нажмите 1", чтобы было понятно что происходит, а то взяли привычку просто по английски отключать. Очень "приятно"! Особенно доставляет, когда организация, на которую почти невозможно повлять вдруг "вспоминает": "О, да у меня же есть пользователи! Ну-ка, позабочусь-ка я о них!"
Такого работодателя ещё поискать. Обычно всё банальней - вместо повышения зарплаты повышают... норму. Поэтому эти сказки про более лучший способ "оценки" эффективности надо оставить совсем уж доверчивым сотрудникам.
“- Товарищ, проходите, это лекция для колхозников” /s
"Я вам сейчас покажу, откуда готовилось вторжение!"
Всегда интересуюсь в таких случаях, а «кто такие мы?» Почему продаем газ мы, а прибыль и сверхдоходы у кого-то одного, в Лондоне, а у меня только зарплата? /S
P.S.
Кстати, по поводу «свалить»: свалили ведь и олигархи тоже, точнее они не возвращались.
По моему это узкое правило нельзя применять в широком смысле. Сразу давать безлимитный кредит доверия незнакомому человеку - так себе идея. Скорее это больше относится к узкому кругу близких знакомых и друзей, с которыми регулярно общаешься и взаимодействуешь и у тебя есть возможность возврата таких моральных долгов. Остальным ещё надо заслужить такое отношение к ним.
Может это было предложение? /s
Ну так меньше года уже осталось, пора новые планы в глаза пускать.
Нет ли тут противоречия предыдущей новости : Зампред Совбеза РФ одобрил использование пиратского контента в условиях санкций ? Особенно с учётом того, что:
А как же ГЛОНАСС? По нему вроде как тоже можно определять координаты? Его планируют отключать или нет?
Так я же не говорил, что задача использовать только одно исключение. Можено, но это не обязательно. Я предлагал пронумеровать все сообщения, которые куда-либо записываются или выводятся.
Так я вот как раз и против такого использования. С моей точки зрения число должно быть одно и оно должно вести к строке исходного кода, где возникла проблемная ситуация - исключение или просто предупреждение (потому что пользователь может быть не согласен с предупреждением и либо надо где-то к номеру привязать более корректное описание или доработать систему). Конечно, в сообщении, которое отображается пользователю могут быть указаны ещё параметры, например, номер транзакции, который сам по себе уникален (и любые другие параметры, которые могут указывать на какой-то бизнес-контекст), но изначально ошибка генерируется в определённом месте программы и нужны её точные "координаты". Это может быть только число (или уникальная строка, но числа всё-таки проще читать и проверять на уникальность, чем рандомные строки).
Честно, я до сих пор не понимаю - traceId он вообще ведёт к точному месту в исходном коде, где возникла ошибка или нет? Или он ведёт к записи в логах и только там можно прочитать внутренние сообщения об ошибках? (но тогда не ясно - а эти сообщения об ошибках точно и однозначно ведут с конкретной строке исходного кода?) Понимаете, я хочу построить однозначный и прозрачный алгоритм сопоставления какого либо/любого сообщения, генерируемого системой (исключение, предупреждение, запись в логи) с конкретной строкой исходного кода, где это сообщение возникло, чтобы любой человек с доступом к исходному коду мог за пару секунд найти эту строку в программе, а только потом разбираться в контексте, что там с бизнес-логикой. TraceId позволяет это сделать? (я надеюсь, что формулировку задачи я выразил полностью?)
P.S.
Я тоже логирую Stacktrace, но его не так просто читать, особенно, когда сообщения об ошибках всплывают из глубины системных библиотек.
P.P.S.
Вот что меня смущает в stacktrace - версионность исходных кодов программы. Как только вы внесёте изменения в программу, то stacktrace становится невалидным и все сообщения, даже имеющие traceid, становятся бесполезными.
Кстати, можно ещё обратить внимание на способ удаления воздуха из корпуса. Т.е. водянка неплохо, но удаление нагретого воздуха - это тоже задача, поэтому без воздушных вентиляторов всё равно не обойтись. А т.к. много тепловыделения идёт на видеокарте, то и, неожиданно, но именно она может самостоятельно заниматься отводом тепла, например, серия (RTX 3080 Turbo), которая самостоятельно удаляет своё тепло из корпуса, а не просто разбрасывает тепло по корпусу огромными вентиляторами, мешая всем.
Я понял что не написал с самого начала. Речь вообще про сообщения при взаимодействии пользователя с сервером, а не только Exception. Сообщения от сервера могут быть очень разнообразными, поэтому я и предлагаю их нумеровать не зависимо от того - это сообщение от исключения или от сообщения от бизнес-правила.
Т.е. у вас UserInputException("E111. Текст1") должно быть одно. Т.е. все сообщения, которые куда-то должны вернуться должны иметь уникальные идентификаторы прямо в тексте: UserInputException("E112. Текст2") /UserInputException("E113. Текст3")/return "E114. Текст4."/Log.Add("E115. Транзакция {NNN} прошла успешно."). Т.е. вообще любое взаимодействие с пользователем, возврат простого сообщения, запись в журнал лога нумеруется уникальным числом и поясняется текстом. Просто сообщения всех устраивают, а уникальные числа в сообщениях почему-то вызывают дискомфорт?
Если так можно выразиться - провести unicalization сообщений. Тогда общение пользователей с техподдержкой и техподдержки с разработчиками становится прозрачным.
Я неоднократно встречался с тем, что получаю сообщение об ошибке в какой-то утилите с исходным кодом, идешь в исходный код, находишь там шаблон этого сообщения и он там встречается 10 раз. Вот какое место в программе выдало моё сообщение об ошибке, когда текстовые шаблоны сообщений одинаковые? - Это уже риторический вопрос, потому что дальше только отладка.
Я имел в виду повторно не встречается в коде.