На счет Copilot - у меня крайне неоднозначные результаты взаимодействия с ним...
Когда надо было с плохо знакомого языка переписать на хорошо знакомый, он помог понять несколько не очевидных моментов и даже пару раз вполне корректно переписал код с одного языка на другой.
Но вот когда он в ревью golang, переменную типа string все время предлагает ее на nil проверить - хочется уже стукнуть его по голове, но не пойму куда бить...
То, что он предлагает добавить по tab чаще мешает чем помогает. Пробовал в комментарии предварительно смысл описать того, что надо реализовать - помогает, но очень незначительно.
В общем и целом - штука может и полезная (ошибки и недочеты правда иногда находит), но в целом я бы не сказал, что он мне поднял производительность.
Все так, но и у нас любят "никогда не..." и прочие повторения "мыльного мыла" для усиления эмоционального смысла сказанного. Вот тот конкретно абзац где прямо так и написали: > Gobierno estuviese realizando un experimento»,[214][215] mientras que el PP, a raíz de la publicación del artículo, acusó directamente al presidente Pedro Sánchez de «ocultar la verdad» sobre las causas del apagón y pidió dimisiones urgentes y una investigación internacional por el «experimento» energético que derivó en el gran apagón.
В ссылка на вики еще есть много статей из СМИ c этим термином.
Только недавно с дочкой в травме получили снимок правой ее ноги при том, что повреждена была левая. Там вполне себе живой интеллект был... а другой RI записал в справку выданную в Июне месяце, что нога повреждена при катании на "сноуборде" (это был глюк voice recognition на слово "скейтборд"). В общем давно я так не ржал как в травме....
Так роботом и шили. Мало инвазивные операции - не новость: в небольшой разрез заводится специальный манипулятор, который и резать и шить может. Так уже давно многие операции делают. Ту скорее всего сердце снизу (вынимали и засовывали, а шили через разрезы между ребрами.
Не совсем уловил от чего бенефиты, если чем выше от земли тем сильнее ветер. Все эти рельсы, тросы - будут регулярно ломаться/рваться. Рельсы еще и смазывать чем-то видимо придется довольно регулярно. Ветряк современный - тоже та еще вундервафля. Но то, что они предлагают выглядит, как минимум, крайне не надежно.
Вы видимо недопоняли про то, что я скриптами локально сохранил.
Конкретно браузер получает серт от сервера (где он лежит, обновленный скриптом) и именно серт проверяется по опять же локально сохраненным ca-certificates (в файловой системе куда браузер имеет доступ). Но вот эта история с CRL - она действительно может все испортить из за некорректной ИМХО реализации в браузере. По идее CRL должен кешироваться и невозможность его обновить не стоит отрабатывать как проблему с сертификатом которого нет в текущей версии списка. Но гуглу конечно виднее что "правильно".
Поясните, плиз, не понял - при чем тут сайт? Серт обновляется скриптом который выполняет несколько запросов, а потом все "причиндалы" серта складываются локально. Браузер, который хочет проверить серт, идет в свое локальное ca-certificates. Где тут завязка на CF после выпуска сертификата?
Сдается мне что проблема именно в желании получать данные максимально часто. Ответьте себе на вопрос: Что конкретно решает отправка с каждого устройства каждые 10 секунд?
Если не нравятся скачущие по карте участники - сделайте в ПО плавное перемещение метки по карте.
Если же важен сам подробный трек, то трекер может отсылать не текущий отсчет, а пакет с несколькими отсчетами сделанными ранее (там по идее можно подумать над эффективной упаковкой на основе метки+[дельты]). Но как по мне, полный трек можно просто в локальную память писать и получить его на "красивой распечатке" на финише.
А вот именно позиции на карте района проведения соревнований - тут мне кажется можно заметно реже отправлять данные - раз в несколько минут. Люди - не ракеты и даже не автомобили. По моему опыту ориентирования, всю дистанцию даже пробежать не все могут, значительную часть маршрута проходится пешком. Средняя скорость от силы километров 5-7 в час.
Этот ноут просто заслужил того, что бы его привели в порядок..... Правда вот есть опасение, что как раз отмывка ила его может и доконать.... Так что стоит это делать максимально осторожно. Буду рад увидеть его отмытым и рабочим в следующей статье.
А что у меня тогда: Common Name (CN) <.......> Organization (O) <Not Part Of Certificate> Organizational Unit (OU) <Not Part Of Certificate> Common Name (CN) E6 Organization (O) Let's Encrypt Organizational Unit (OU) <Not Part Of Certificate> Issued On Saturday, April 26, 2025 at 3:10:27 PM Expires On Friday, July 25, 2025 at 3:10:26 PM
Ошибок в логах обновления сертификатов не вижу.
Проверки для сейчас его без проблем обновил:
Issued On Friday, June 27, 2025 at 11:02:31 PM Expires On Thursday, September 25, 2025 at 11:02:30 PM
Да я без претензий, в вашей концепции есть неплохая, интересная идея... И я пытаюсь ее натянуть на разные сценарии.
Только вот я в логгировани пришел немного к другому подходу.
Я в одном проекте сделал так, что по сути выводится только уведомления о важных событиях и ошибки. Так вот понимая сложность сбора контекста ошибки у меня ошибка собирается с деталями по всему стеку вызова и вот с ее адекватным форматированием (с учетом ограничения на длину строки) пришлось повозится изрядно. Но в такой схеме debug вообще не нужен. Я там в ошибку выкидываю все, что нужно для того, что бы понять почему именно там произошла ошибка, где и с какими данными.
Один раз правда не хватило этого пришлось снимать трейсы, что бы понять, что там внезапно начинает выедать один CPU.
Но тот косяк логгированием, то было не покрыть. По крайней мере я не смог придумать, для чего бы там нужно было такое логгирование, которое смогло бы по логам дать понять, что произошло.
Ок, может в варианте с HTTP сервером, оно и сработает как надо, но вот давайте возьмем сервис у которого нет запросов снаружи кроме служебных (типа за метриками пришел кто-то). Он сам берет где-то и кладет куда-то, тут контекст уже может быть размазан, и тут оптимально сделать просто центральный логгер не смотря на то, что обработка может быть во многих параллельных потоках.
Для этого нужно в каждый хендлер вставлять свой логгер-обертку. Такое не слишком удобно. Логгирование проще делать централизованно либо как топлевел мидлвере, либо вообще что-то глобальное.
Как по мне можно было чуть детальнее рассказать именно концепцию. Потому как именно про то "как оно работает" - в статье ничего нет, приходится догадываться по не совсем вразумительной схеме, которая никак не учитывает такой "мелочи" как время событий....
По концепции, как я ее понял, вижу следующие проблему: - когда в логе появилась ошибка, то ее причины могут быть глубоко в дебаг-логах ранее, а последствия могут отразиться в логах и за первой ошибкой. Как принять решение, что именно выбросить в оутпут, а что откинуть? Тут есть опасность, что в буфере уже не осталось первопричины. И вообще не понятно сколько выводить после ошибки.
Допустим API отдает огромные простынки ответов, их что бы полностью вывести (с учетом того что эти логи нужно как-то обрабатывать) иногда приходится делить на несколько строк да еще при этом вводить искусственный ID и порядковый номер для того, чтобы потом можно было собрать и запрос и разбитый на части ответ на него (ведь логи могут писаться параллельно из множества потоков). И такая ситуация - отнюдь не редкость. И вот тут в сообщениях может быть такая набивка из соседних потоков, что никаких буферов не хватит, чтобы собрать нужный ответ после ошибки.
Напрашивается выделение по потокам и выброс из буфера в оутпут только того дебага, который относится к потоку, выдавшего ошибку. Но тут еще придется извратится с идентификацией потоков и уже не обойтись без парсинга логов в логгере. Что делает из логгера уже какой-то комбайн....
На счет Copilot - у меня крайне неоднозначные результаты взаимодействия с ним...
Когда надо было с плохо знакомого языка переписать на хорошо знакомый, он помог понять несколько не очевидных моментов и даже пару раз вполне корректно переписал код с одного языка на другой.
Но вот когда он в ревью golang, переменную типа string все время предлагает ее на nil проверить - хочется уже стукнуть его по голове, но не пойму куда бить...
То, что он предлагает добавить по tab чаще мешает чем помогает. Пробовал в комментарии предварительно смысл описать того, что надо реализовать - помогает, но очень незначительно.
В общем и целом - штука может и полезная (ошибки и недочеты правда иногда находит), но в целом я бы не сказал, что он мне поднял производительность.
MR от Copilot - спасибо, не надо.
Клипом хорошую песню испортили....
Тогда уж передача накопленных пакетов и показ с задержкой. Все будет динамично но чутка с задержкой, но задержка смысла шоу не меняет.
А кто-то реально по письмам серты менял каждые три месяца из года в год, вместо того что бы один раз крон настроить?
Все так, но и у нас любят "никогда не..." и прочие повторения "мыльного мыла" для усиления эмоционального смысла сказанного.
Вот тот конкретно абзац где прямо так и написали:
> Gobierno estuviese realizando un experimento»,[214][215] mientras que el PP, a raíz de la publicación del artículo, acusó directamente al presidente Pedro Sánchez de «ocultar la verdad» sobre las causas del apagón y pidió dimisiones urgentes y una investigación internacional por el «experimento» energético que derivó en el gran apagón.
В ссылка на вики еще есть много статей из СМИ c этим термином.
В СССР еще и налог не бездетность был....
Только недавно с дочкой в травме получили снимок правой ее ноги при том, что повреждена была левая. Там вполне себе живой интеллект был... а другой RI записал в справку выданную в Июне месяце, что нога повреждена при катании на "сноуборде" (это был глюк voice recognition на слово "скейтборд"). В общем давно я так не ржал как в травме....
Так роботом и шили.
Мало инвазивные операции - не новость: в небольшой разрез заводится специальный манипулятор, который и резать и шить может. Так уже давно многие операции делают. Ту скорее всего сердце снизу (вынимали и засовывали, а шили через разрезы между ребрами.
Не совсем уловил от чего бенефиты, если чем выше от земли тем сильнее ветер. Все эти рельсы, тросы - будут регулярно ломаться/рваться. Рельсы еще и смазывать чем-то видимо придется довольно регулярно. Ветряк современный - тоже та еще вундервафля. Но то, что они предлагают выглядит, как минимум, крайне не надежно.
Вы видимо недопоняли про то, что я скриптами локально сохранил.
Конкретно браузер получает серт от сервера (где он лежит, обновленный скриптом) и именно серт проверяется по опять же локально сохраненным ca-certificates (в файловой системе куда браузер имеет доступ). Но вот эта история с CRL - она действительно может все испортить из за некорректной ИМХО реализации в браузере. По идее CRL должен кешироваться и невозможность его обновить не стоит отрабатывать как проблему с сертификатом которого нет в текущей версии списка. Но гуглу конечно виднее что "правильно".
Поясните, плиз, не понял - при чем тут сайт? Серт обновляется скриптом который выполняет несколько запросов, а потом все "причиндалы" серта складываются локально. Браузер, который хочет проверить серт, идет в свое локальное ca-certificates. Где тут завязка на CF после выпуска сертификата?
Сдается мне что проблема именно в желании получать данные максимально часто. Ответьте себе на вопрос: Что конкретно решает отправка с каждого устройства каждые 10 секунд?
Если не нравятся скачущие по карте участники - сделайте в ПО плавное перемещение метки по карте.
Если же важен сам подробный трек, то трекер может отсылать не текущий отсчет, а пакет с несколькими отсчетами сделанными ранее (там по идее можно подумать над эффективной упаковкой на основе метки+[дельты]). Но как по мне, полный трек можно просто в локальную память писать и получить его на "красивой распечатке" на финише.
А вот именно позиции на карте района проведения соревнований - тут мне кажется можно заметно реже отправлять данные - раз в несколько минут. Люди - не ракеты и даже не автомобили. По моему опыту ориентирования, всю дистанцию даже пробежать не все могут, значительную часть маршрута проходится пешком. Средняя скорость от силы километров 5-7 в час.
Этот ноут просто заслужил того, что бы его привели в порядок.....
Правда вот есть опасение, что как раз отмывка ила его может и доконать.... Так что стоит это делать максимально осторожно.
Буду рад увидеть его отмытым и рабочим в следующей статье.
А что у меня тогда:
Common Name (CN)
<.......>
Organization (O)
<Not Part Of Certificate>
Organizational Unit (OU)
<Not Part Of Certificate>
Common Name (CN)
E6
Organization (O)
Let's Encrypt
Organizational Unit (OU)
<Not Part Of Certificate>
Issued On
Saturday, April 26, 2025 at 3:10:27 PM
Expires On
Friday, July 25, 2025 at 3:10:26 PM
Ошибок в логах обновления сертификатов не вижу.
Проверки для сейчас его без проблем обновил:
Issued On
Friday, June 27, 2025 at 11:02:31 PM
Expires On
Thursday, September 25, 2025 at 11:02:30 PM
Да я без претензий, в вашей концепции есть неплохая, интересная идея... И я пытаюсь ее натянуть на разные сценарии.
Только вот я в логгировани пришел немного к другому подходу.
Я в одном проекте сделал так, что по сути выводится только уведомления о важных событиях и ошибки. Так вот понимая сложность сбора контекста ошибки у меня ошибка собирается с деталями по всему стеку вызова и вот с ее адекватным форматированием (с учетом ограничения на длину строки) пришлось повозится изрядно. Но в такой схеме debug вообще не нужен. Я там в ошибку выкидываю все, что нужно для того, что бы понять почему именно там произошла ошибка, где и с какими данными.
Один раз правда не хватило этого пришлось снимать трейсы, что бы понять, что там внезапно начинает выедать один CPU.
Но тот косяк логгированием, то было не покрыть. По крайней мере я не смог придумать, для чего бы там нужно было такое логгирование, которое смогло бы по логам дать понять, что произошло.
Ок, может в варианте с HTTP сервером, оно и сработает как надо, но вот давайте возьмем сервис у которого нет запросов снаружи кроме служебных (типа за метриками пришел кто-то). Он сам берет где-то и кладет куда-то, тут контекст уже может быть размазан, и тут оптимально сделать просто центральный логгер не смотря на то, что обработка может быть во многих параллельных потоках.
Для этого нужно в каждый хендлер вставлять свой логгер-обертку. Такое не слишком удобно. Логгирование проще делать централизованно либо как топлевел мидлвере, либо вообще что-то глобальное.
Как по мне можно было чуть детальнее рассказать именно концепцию. Потому как именно про то "как оно работает" - в статье ничего нет, приходится догадываться по не совсем вразумительной схеме, которая никак не учитывает такой "мелочи" как время событий....
По концепции, как я ее понял, вижу следующие проблему:
- когда в логе появилась ошибка, то ее причины могут быть глубоко в дебаг-логах ранее, а последствия могут отразиться в логах и за первой ошибкой. Как принять решение, что именно выбросить в оутпут, а что откинуть? Тут есть опасность, что в буфере уже не осталось первопричины. И вообще не понятно сколько выводить после ошибки.
Допустим API отдает огромные простынки ответов, их что бы полностью вывести (с учетом того что эти логи нужно как-то обрабатывать) иногда приходится делить на несколько строк да еще при этом вводить искусственный ID и порядковый номер для того, чтобы потом можно было собрать и запрос и разбитый на части ответ на него (ведь логи могут писаться параллельно из множества потоков). И такая ситуация - отнюдь не редкость. И вот тут в сообщениях может быть такая набивка из соседних потоков, что никаких буферов не хватит, чтобы собрать нужный ответ после ошибки.
Напрашивается выделение по потокам и выброс из буфера в оутпут только того дебага, который относится к потоку, выдавшего ошибку. Но тут еще придется извратится с идентификацией потоков и уже не обойтись без парсинга логов в логгере. Что делает из логгера уже какой-то комбайн....
Попробуйте сравнить бенчи клаcсического sort и slices на дженениках.
27? Серьезно? Ну тогда нечего боятся этих LLM-ов.
Вот если бы ответили 42 - тогда бы было страшно :)