Ну если бы лог в примере сам по себе не был таким паршивым, то и без трейсов можно было бы жить. Если что, так request id можно и от сервиса к сервису передавать, и сюрприз: тогда и по 10 микросервисам можно цельную картину собрать.
Для разбора проблемы Connection timeout трейс не нужен. Какую полезную информацию вы получите, если увидите, что до возникновения этой ошибки вызов прошёл через 5 других сервисов? — Никакую. Тут нужен просто более детальный лог именно из места возникновения ошибки.
С примером, в котором AcquireLock обмазан спаном, тоже есть проблема. Если вы будете каждое такое место обмазывать, то при нормальной нагрузке любой коллектор отъедет. И всякий раз будет дилемма: нужен тут спан или нет? В конечном счёте всё равно понадобится дополнительная отладка. Ну или бюджет на джагер, сравнимый с бюджетом остальной инфры.
Спаны в библиотеке редиса — тоже беда. Я вот буквально пару месяцев назад обмазывал платформенные библиотеки спанами, и в редисе я сознательно коснулся только тех команд, которые связаны с его брокерским альтер эго. Потому что остальные команды используются ровно в тех случаях, когда важна скорость. Эти вызовы происходят слишком часто. Поэтому было странно обременять накладной нагрузкой get, set и т.п. — облегчённую и эффективную.
Короче говоря, приведённые примеры напоминают тех неуклюжек, которые без специального устройства не могут бутылку воды открыть, чтоб не ушататься головой о кухонный шкафчик ;)
Трейсы полезны и важны там, где есть сложное взаимодействие, где синхронщина переплетается с асинхронщиной с петлями и другими фокусами. А в приведенных вами случаях нужны вменяемые логи и кибана.
А к чему этот модуль подключается, что его собственный 4-пиновый интерфейс подходит к любой марке-модели? Ну и "команда", которую отправляете в машину, — это что за команда такая, которая тоже любой машине подходит, только слово может отличаться? Возможно, у меня бы не возникло этих вопросов, если бы про чайник было более подробно изложено, а не просто упомянуто ;)
Вот я с друганами, которые гораздо сильнее меня в математике и тервере, так же про Монти-Холла спорил. Мне тоже казалось, что там речь идёт о двух слабо связанных задачах (как вы выразились), но я не мог тогда это внятно донести. И вот читая эту статью, я сразу же определил правильный ответ (по мнению её автора), как раз памятуя о том споре. Из спора того я вынес следующие: это не две разных задачи, а два выражения, и вот их-то и нужно решать именно таким образом — системно.
Эта задача про сестёр — гораздо более наглядный пример того же, что показывает Монти-Холл, как по мне. Разумеется, если оставить в стороне биологию и проч.
Такой замах, что я думал, вы там механическую обратную связь в него вкорячите, -- чтобы при софтварном переключении качелька физически становилась в правильное положение. Придётся ещё подождать :)
Но и так годно: экономия выглядит внушительной. Как я понимаю, неучтёнными остались только acdc и затраченное время?
Вы совсем необязательно сериализуете/десериализуете структуры бизнес-логики. Это вполне могут быть и структуры адаптера (в терминологии гексагоналки), которые впоследствии и конвертируются во внутренние представления. А маршалинг всё равно нужен (в основном тут-то он и нужен!)
Что же до магии, то когда вы имеете дело с двумя такими структурами по три варианта, то да, — можно и без этого всего, но с Marshaler/Unmarshaler: так будет легче разобраться. Но когда доходит до десятков, то оказывается куда легче разобраться в библиотечной магии, чем в таком количестве пусть и явных, но чрезмерно многословных преобразователях. В конечном счёте вы всё равно сделаете десяток своих хелперов, в которых тоже нужно будет разбираться; и не исключено, что они покажутся почти такими же магическими.
Формулировки у него такие-себе. Но если не потерять суть, изложенную двумя абзацами выше, то становится понятно, что под "двумя объектами" подразумеваются-таки фермионы: электрон и позитрон. Поэтому Паули присматривает за ними.
Остальное я не очень разумею, так что удаляюсь. Хотел только намекнуть на неуместный пример с бозонами.
Ерунда какая-то. В заголовке чёткая отсылка к default, как к чуть ли не единственному спасательному кругу. В теле же — ни единого примера ситуации, в которой можно было бы как-то этим кругом воспользоваться. Зато куча примеров просто ошибочного кода. Ну понятно, что вечная блокировка — плохо. Это и без статьи вроде понятно. А коли это понятно, то понятны должны быть и способы избавления от этого плохого. Так а default-то тут при чём? Она ж просто другую логику позволяет реализовать, причём совершенно несовместимую с логикой без default.
Физический размер к этому показателю не имеет отношения. Значение 1 означает, что выбранное разрешение для видяхи (логистический пиксель) в точности соответствует разрешению дисплея (физический пиксель — который светится). А отличаться от 1 оно будет в том случае, если на дисплее, скажем, 1024х768 выводить изображение другого разрешения
Прошу, объясните дураку: почему они не режут траф на уровне ip (ну или tcp/udp на худой конец)? Только не говорите, что боятся заблокировать что-то лишнее. Особенно в дни, когда не несколько сервисов на одном адресе висят, а наоборот — один сервис на десятке разных адресов. Ну разве не проще хранить чёрный список ипов, и зарезать их?
Только не fmt.Sprintf("Unexpected ... detail: %w", err), а fmt.Errorf(...)
Ещё забыли отметить важный момент, как мне кажется. Ошибки, коды и детальки нередко критически влияют на работу мидлварь, которые чаще всего сторонние, и опираются на стандарт. Понятно, что это часть той самой «системы в целом». Но сначала иногда думается, что система в целом будет замкнутой, и на подключаемые мидлвари часто начинают обращать внимание уже на полпути к завершению проектирования. И тогда приходится пересматривать коды ошибок и обработки ради подключения какого-нибудь ретрая.
Вот именно. И dst, и сами таймзоны меняются периодически. Поэтому для полного понимания нужно после наименования зоны указывать ещё и текущий таймстамп, чтобы обозначить время применения смещения. И вдобавок иметь под рукой справочник: таак, вот в 12 ночи такого-то числа 2013 года отменили dst; потом тогда-то вернули.
А для указания времени применения тоже ведь нужно часовой пояс указать. Так, погодите-ка...
Странно, что ни слова про собственно BLE, даже невооружённым взглядом. Вся эта длинная статья могла бы хотя бы называться по-другому. Разобраться с BLE интересно. Надеюсь, следующая статья не будет про какой-нибудь gradle и альтернативы ;)
Ну если бы лог в примере сам по себе не был таким паршивым, то и без трейсов можно было бы жить. Если что, так request id можно и от сервиса к сервису передавать, и сюрприз: тогда и по 10 микросервисам можно цельную картину собрать.
Для разбора проблемы Connection timeout трейс не нужен. Какую полезную информацию вы получите, если увидите, что до возникновения этой ошибки вызов прошёл через 5 других сервисов? — Никакую. Тут нужен просто более детальный лог именно из места возникновения ошибки.
С примером, в котором AcquireLock обмазан спаном, тоже есть проблема. Если вы будете каждое такое место обмазывать, то при нормальной нагрузке любой коллектор отъедет. И всякий раз будет дилемма: нужен тут спан или нет? В конечном счёте всё равно понадобится дополнительная отладка. Ну или бюджет на джагер, сравнимый с бюджетом остальной инфры.
Спаны в библиотеке редиса — тоже беда. Я вот буквально пару месяцев назад обмазывал платформенные библиотеки спанами, и в редисе я сознательно коснулся только тех команд, которые связаны с его брокерским альтер эго. Потому что остальные команды используются ровно в тех случаях, когда важна скорость. Эти вызовы происходят слишком часто. Поэтому было странно обременять накладной нагрузкой get, set и т.п. — облегчённую и эффективную.
Короче говоря, приведённые примеры напоминают тех неуклюжек, которые без специального устройства не могут бутылку воды открыть, чтоб не ушататься головой о кухонный шкафчик ;)
Трейсы полезны и важны там, где есть сложное взаимодействие, где синхронщина переплетается с асинхронщиной с петлями и другими фокусами. А в приведенных вами случаях нужны вменяемые логи и кибана.
Тут ожидаешь каких-то деталей, погружения в специфику вопроса, описание процессов на стыке биологии и физики. А есть только новостная заметка. Не то
Не про бейсбол, а про кусь!
А к чему этот модуль подключается, что его собственный 4-пиновый интерфейс подходит к любой марке-модели? Ну и "команда", которую отправляете в машину, — это что за команда такая, которая тоже любой машине подходит, только слово может отличаться? Возможно, у меня бы не возникло этих вопросов, если бы про чайник было более подробно изложено, а не просто упомянуто ;)
Вот я с друганами, которые гораздо сильнее меня в математике и тервере, так же про Монти-Холла спорил. Мне тоже казалось, что там речь идёт о двух слабо связанных задачах (как вы выразились), но я не мог тогда это внятно донести. И вот читая эту статью, я сразу же определил правильный ответ (по мнению её автора), как раз памятуя о том споре. Из спора того я вынес следующие: это не две разных задачи, а два выражения, и вот их-то и нужно решать именно таким образом — системно.
Эта задача про сестёр — гораздо более наглядный пример того же, что показывает Монти-Холл, как по мне. Разумеется, если оставить в стороне биологию и проч.
Такой замах, что я думал, вы там механическую обратную связь в него вкорячите, -- чтобы при софтварном переключении качелька физически становилась в правильное положение. Придётся ещё подождать :)
Но и так годно: экономия выглядит внушительной. Как я понимаю, неучтёнными остались только acdc и затраченное время?
Бод в секунду -- это ускорение получается ;)
Вы совсем необязательно сериализуете/десериализуете структуры бизнес-логики. Это вполне могут быть и структуры адаптера (в терминологии гексагоналки), которые впоследствии и конвертируются во внутренние представления. А маршалинг всё равно нужен (в основном тут-то он и нужен!)
Что же до магии, то когда вы имеете дело с двумя такими структурами по три варианта, то да, — можно и без этого всего, но с Marshaler/Unmarshaler: так будет легче разобраться. Но когда доходит до десятков, то оказывается куда легче разобраться в библиотечной магии, чем в таком количестве пусть и явных, но чрезмерно многословных преобразователях. В конечном счёте вы всё равно сделаете десяток своих хелперов, в которых тоже нужно будет разбираться; и не исключено, что они покажутся почти такими же магическими.
Формулировки у него такие-себе. Но если не потерять суть, изложенную двумя абзацами выше, то становится понятно, что под "двумя объектами" подразумеваются-таки фермионы: электрон и позитрон. Поэтому Паули присматривает за ними.
Остальное я не очень разумею, так что удаляюсь. Хотел только намекнуть на неуместный пример с бозонами.
Ерунда какая-то. В заголовке чёткая отсылка к default, как к чуть ли не единственному спасательному кругу. В теле же — ни единого примера ситуации, в которой можно было бы как-то этим кругом воспользоваться. Зато куча примеров просто ошибочного кода. Ну понятно, что вечная блокировка — плохо. Это и без статьи вроде понятно. А коли это понятно, то понятны должны быть и способы избавления от этого плохого. Так а default-то тут при чём? Она ж просто другую логику позволяет реализовать, причём совершенно несовместимую с логикой без default.
Физический размер к этому показателю не имеет отношения. Значение 1 означает, что выбранное разрешение для видяхи (логистический пиксель) в точности соответствует разрешению дисплея (физический пиксель — который светится). А отличаться от 1 оно будет в том случае, если на дисплее, скажем, 1024х768 выводить изображение другого разрешения
Прошу, объясните дураку: почему они не режут траф на уровне ip (ну или tcp/udp на худой конец)? Только не говорите, что боятся заблокировать что-то лишнее. Особенно в дни, когда не несколько сервисов на одном адресе висят, а наоборот — один сервис на десятке разных адресов. Ну разве не проще хранить чёрный список ипов, и зарезать их?
Только не
fmt.Sprintf("Unexpected ... detail: %w", err), аfmt.Errorf(...)Ещё забыли отметить важный момент, как мне кажется. Ошибки, коды и детальки нередко критически влияют на работу мидлварь, которые чаще всего сторонние, и опираются на стандарт. Понятно, что это часть той самой «системы в целом». Но сначала иногда думается, что система в целом будет замкнутой, и на подключаемые мидлвари часто начинают обращать внимание уже на полпути к завершению проектирования. И тогда приходится пересматривать коды ошибок и обработки ради подключения какого-нибудь ретрая.
Вот именно. И dst, и сами таймзоны меняются периодически. Поэтому для полного понимания нужно после наименования зоны указывать ещё и текущий таймстамп, чтобы обозначить время применения смещения. И вдобавок иметь под рукой справочник: таак, вот в 12 ночи такого-то числа 2013 года отменили dst; потом тогда-то вернули.
А для указания времени применения тоже ведь нужно часовой пояс указать. Так, погодите-ка...
Это для чего? Для восстановления после неполной записи в основную область при обновлении?
Вы же не имеете в виду порты, которые бы торчали вверх из окошка бывшего сканера отпечатков?
Странно, что ни слова про собственно BLE, даже невооружённым взглядом. Вся эта длинная статья могла бы хотя бы называться по-другому. Разобраться с BLE интересно. Надеюсь, следующая статья не будет про какой-нибудь gradle и альтернативы ;)
Ага, а когда кто-то хоть на шаг отступает от этого принципа, про это событие статьи пишут. А маркетологи киллер-фичами называют )
По определению Евклида
Дока тоже генерится, но с помощью ещё одного генератора protoc-gen-openapiv2