В тексте есть ошибка в иллюстрации. В блоке, где описывается VDUP для двойной точности (с текстом "То же самое с double precision:") должно быть VDUP R0, V0.D4.
Ещё одно из правил, как определять значение/указатель в приёмщике типа в методах (хотя скорее это расширение тезиса про сущность, которая в программе должна присутствовать в единственном экземпляре - как с User из статьи): если в поле структуры содержится тип-мьютекс (например, sync.Mutex), блокирующий структуру, то приёмщик всегда должен быть в форме указателя, иначе эта блокировка просто не будет работать.
методы Get() и Store() должны быть определены для указателя на Counters, а не на Counters (тоесть не func (c Counters) Load(key string) int { ... }, потому что в таком случае значение ресивера (c) копируется, вместе с чем скопируется и мьютекс в нашей структуре, что лишает всю затею смысла и приводит к проблемам. Отсюда https://habr.com/ru/articles/338718/
В Neovim :vimtutor не работает из коробки (по крайней мере в сборке на Ubuntu из ppa:neovim-ppa/stable). Чтобы его пройти используйте :Tutor или :help nvim
@Rast1234Огромное спасибо за цикл! Однозначно не хватает статьи (или может даже цикла) про Графану, потому что там тоже свои приколы для разных видов визуализаций. Очень бы хотелось почитать про советы по визуализации для разных типов метрик Прометея.
Ещё хотелось бы заметить, что функция rate несмотря на всю пользу, что она несёт (сглаживание нулей и визуализация выбросов на счётчиках), усложняет интерпретацию данных, так как на оси ординат в Графане вместо абсолютного значения (например, количество запросов со статусом 500 за последний час) мы видим непонятные дроби. В этом смысле может помочь вычисление дельты для метрики (из агрегированноего значения вычитаем его же, но с offset 5m например).
Это отличный доклад для быстрого освоения golangci-lint. Уже не один раз обращался к нему при настройке линтера. Хотелось бы добавить несколько моментов, которые могут помочь при внедрении этого инструмента в проект (хотел бы я знать всё это раньше!). Перечислять буду в режиме блица:
- не надейтесь на конфигурацию линтера из коробки - некоторые линтеры в ней ничего не проверяют. Лучше настроить всё самому, пройдясь по примеру конфигурации самостоятельно https://github.com/golangci/golangci-lint/blob/master/.golangci.reference.yml Так вы будете понимать, что и как проверяется. Где надо сможете усилить проверки, где не надо - наборот, ослабить (например цикломатическая сложность, длина строк, расположение типов, костант, переменных в файлах - всё это достаточно сложно править в уже существующем проекте, поэтому есть смысл настроить конкретные линтеры под проект, чем расставлять везде nolint или выключать сам линтер). Нужно прямо скопировать конфигурацию полинтерно к себе и поменять. Не надейтесь только на секции enable, disabled в linters.
- по умолчанию лучше все линтеры включить, выключив только deprecated линтеры и то, что кажется неважным лично вам (например, некоторые стилевые линтеры, проверку орфографии в комментариях и т.д.), также нужно использовать golangci-lint-version из доклада, чтобы при обновлении не включались свежедобавленные линтеры. По мере обновления golangci-lint конфигурацию в проекте нужно сверять с https://github.com/golangci/golangci-lint/blob/master/.golangci.reference.yml - искать новое, сравнивать значения по умолчанию.
- бывает, что даже настроив конфиг по совету выше, оказывается, что golangci-lint нашёл как-то подозрительно мало проблем. Это может быть из-за невалидного yaml в вашем .golangci.yml файле. Такое может быть из-за неправильных отступов, перемешанных табов и пробелов... Чтобы узнать, какие конкретно линтеры из конфигурации используются на запуске, добавляйте флаг golangci-lint run -vvv ./... Сравните вывод из строчки вида "INFO [lintersdb] Active 81 linters: ..." с вашим конфигом и выводом golangci-lint linters.
- бывает такое, что вроде все замечания расчистил, но при следующем запуске линтер выдаёт порцию новых. Это связано с настройками max-issues-per-linter (50 по умолчанию) и max-same-issues (3 по умолчанию). В конфигурации лучше для них оставить 0, чтобы не схлопывать сходные замечания, а при запуске, чтобы оценить фронт работ и уменьшит шум, наоброт добавить вот так: golangci-lint run --max-issues-per-linter 2 --max-same-issues 2 ./... -vvv >> issues.txt
- при глушении замечний в конкретном месте через nolint всегда нужно писать причину, идеально если todo с каким-то планом исправления.
Спасибо за статью. Есть вопрос: если ретраи реализованы на reverse_proxy и выбрана стратегия фиксированого ретрая (например, 3 попытки с 1-секундным перерывом между ними), то процесс PHP всё это время висит ожидая ответа? И получает ошибку от reverse_proxy по истечении 3 секунд?
Спасибо вам. Только начал изучать Airflow, и не покидало ощущение, что с ним что-то не так. Статья по ссылке прояснила моё смутное недовольство: инструмент по оркестрации берёт на себя слишком много и начинает мешать в одну кучу и оркестрацию, и логику задач.
Я начал практиковать Дзен в 2006 году. То, что мне пришло в голову через довольно большое время — старые мастера Дзен уже знали сотни лет назад, как сегодняшние программисты должны работать.
Haskell? You are doing it wrong, silly white man.
Видимо этот программист ещё не постиг суть дзен, раз написал столько букв.
Вообще-то, следует уточноить, что бесплатно доступна будет не полная версия книги, а только первые 6 глав.
And the best part is that not only is the workshop itself free, but you’ll also get free acccess to the first 6 chapters of the book (see the full table of contents).
Кстати, Михаил Абызов (http://goo.gl/4Yq3f) — преинтереснейшая личность. В своё время именно он решал вместе с Чубайсом кризис неплатежей в РАО ЕЭС. Потом создал одну из крупнейших инжиниринговых компаний (E4).
На самом деле занятно, что он решил инвестировать в IT. У меня невольно возникает в голове сопоставление с Юрием Мильнером.
Кстати, вот это отсутсвие оавтоопредления кодировки и невозможность её смены для файла очень портит настроение, когда в проекте есть комментарии на кириллице. Сам я пишу комментарии только на английском, но другие программисты так не делают.
Всё в итоге они превращается в знаки вопроса.
Спасибо за цикл!
В тексте есть ошибка в иллюстрации. В блоке, где описывается VDUP для двойной точности (с текстом "То же самое с double precision:") должно быть VDUP R0, V0.D4.
https://github.com/ergo-services/ergo
Ещё одно из правил, как определять значение/указатель в приёмщике типа в методах (хотя скорее это расширение тезиса про сущность, которая в программе должна присутствовать в единственном экземпляре - как с User из статьи): если в поле структуры содержится тип-мьютекс (например,
sync.Mutex), блокирующий структуру, то приёмщик всегда должен быть в форме указателя, иначе эта блокировка просто не будет работать.методы
Get()иStore()должны быть определены для указателя наCounters, а не наCounters(тоесть неfunc (c Counters) Load(key string) int { ... }, потому что в таком случае значение ресивера (c) копируется, вместе с чем скопируется и мьютекс в нашей структуре, что лишает всю затею смысла и приводит к проблемам.Отсюда https://habr.com/ru/articles/338718/
В Neovim :vimtutor не работает из коробки (по крайней мере в сборке на Ubuntu из ppa:neovim-ppa/stable). Чтобы его пройти используйте :Tutor или :help nvim
@Rast1234Огромное спасибо за цикл! Однозначно не хватает статьи (или может даже цикла) про Графану, потому что там тоже свои приколы для разных видов визуализаций. Очень бы хотелось почитать про советы по визуализации для разных типов метрик Прометея.
Ещё хотелось бы заметить, что функция rate несмотря на всю пользу, что она несёт (сглаживание нулей и визуализация выбросов на счётчиках), усложняет интерпретацию данных, так как на оси ординат в Графане вместо абсолютного значения (например, количество запросов со статусом 500 за последний час) мы видим непонятные дроби. В этом смысле может помочь вычисление дельты для метрики (из агрегированноего значения вычитаем его же, но с offset 5m например).
Это отличный доклад для быстрого освоения golangci-lint. Уже не один раз обращался к нему при настройке линтера. Хотелось бы добавить несколько моментов, которые могут помочь при внедрении этого инструмента в проект (хотел бы я знать всё это раньше!). Перечислять буду в режиме блица:
- не надейтесь на конфигурацию линтера из коробки - некоторые линтеры в ней ничего не проверяют. Лучше настроить всё самому, пройдясь по примеру конфигурации самостоятельно https://github.com/golangci/golangci-lint/blob/master/.golangci.reference.yml Так вы будете понимать, что и как проверяется. Где надо сможете усилить проверки, где не надо - наборот, ослабить (например цикломатическая сложность, длина строк, расположение типов, костант, переменных в файлах - всё это достаточно сложно править в уже существующем проекте, поэтому есть смысл настроить конкретные линтеры под проект, чем расставлять везде nolint или выключать сам линтер). Нужно прямо скопировать конфигурацию полинтерно к себе и поменять. Не надейтесь только на секции enable, disabled в linters.
- по умолчанию лучше все линтеры включить, выключив только deprecated линтеры и то, что кажется неважным лично вам (например, некоторые стилевые линтеры, проверку орфографии в комментариях и т.д.), также нужно использовать golangci-lint-version из доклада, чтобы при обновлении не включались свежедобавленные линтеры. По мере обновления golangci-lint конфигурацию в проекте нужно сверять с https://github.com/golangci/golangci-lint/blob/master/.golangci.reference.yml - искать новое, сравнивать значения по умолчанию.
- бывает, что даже настроив конфиг по совету выше, оказывается, что golangci-lint нашёл как-то подозрительно мало проблем. Это может быть из-за невалидного yaml в вашем .golangci.yml файле. Такое может быть из-за неправильных отступов, перемешанных табов и пробелов... Чтобы узнать, какие конкретно линтеры из конфигурации используются на запуске, добавляйте флаг golangci-lint run -vvv ./... Сравните вывод из строчки вида "INFO [lintersdb] Active 81 linters: ..." с вашим конфигом и выводом golangci-lint linters.
- бывает такое, что вроде все замечания расчистил, но при следующем запуске линтер выдаёт порцию новых. Это связано с настройками max-issues-per-linter (50 по умолчанию) и max-same-issues (3 по умолчанию). В конфигурации лучше для них оставить 0, чтобы не схлопывать сходные замечания, а при запуске, чтобы оценить фронт работ и уменьшит шум, наоброт добавить вот так:
golangci-lint run --max-issues-per-linter 2 --max-same-issues 2 ./... -vvv >> issues.txt
- при глушении замечний в конкретном месте через nolint всегда нужно писать причину, идеально если todo с каким-то планом исправления.
На bash жизнь тоже есть. https://github.com/Bash-it/bash-it
Спасибо за статью. Есть вопрос: если ретраи реализованы на reverse_proxy и выбрана стратегия фиксированого ретрая (например, 3 попытки с 1-секундным перерывом между ними), то процесс PHP всё это время висит ожидая ответа? И получает ошибку от reverse_proxy по истечении 3 секунд?
Slack можно прекрасно заменить на открытый Mattermost.
Haskell? You are doing it wrong, silly white man.
Видимо этот программист ещё не постиг суть дзен, раз написал столько букв.
Ссылка на пост в блоге
На самом деле занятно, что он решил инвестировать в IT. У меня невольно возникает в голове сопоставление с Юрием Мильнером.
Всё в итоге они превращается в знаки вопроса.