"Загорелая снежинка", "лид начал ныть". Я думаю, если б автор текста не ушел сам, топнув ножкой, то его надо было бы все равно гнать обратно в ту помойку, где так принято общаться.
Нигде не спрятана, это потенциальная энергия железки в поле магнита. Когда железка прилепляется, она переходит в кинетическую, а когда вы ее отлепляете, то совершаете работу в этом поле.
Точно так же у вас самих есть запас потенциальной энергии в, например, гравитационном поле Луны.
Спасибо за ссылку. Посмотрел мельком на апи - лонг поллинг для грпц, как по мне, странная идея, если есть стримы.
И, что интересно, я специально искал все возможные варианты подобных опенсорсных штук прежде чем пилить свою - и не нашел вот это проект, хотя ключевые слова абсолютно совпадают.
Буферизированные каналы - в 95% пахнущий кусок кода, который требует убедительного обоснования
Можно читать и писать значения в массиве по индексам, если разные горутины используют разные индексы для этого.
Утверждение правильное, но я бы сказал, что опасное, особенно для новичков - надо очень хорошо понимать ref/spec и ref/mem чтобы знать, где можно (например, с доступом по индексам), а где нельзя (например, append)
Стоит отметить, что это не настоящие квантили, а приблизительно вычисленные из гистограммы, и чем меньше бакетов, тем меньше точность. Честно и эффективно считать квантили на потоковых данных - это та еще задачка, к которой пром, кажется, и не подступался, в отличие от, например, m3db.
Я б сказал, что для визуализации гистограмм больше подходят хитмапы, они вам и покажут именно то, что хранится, у них и плотность информации больше (видно не только латенси, но и ее распределение). Но читать их, конечно, сложнее.
На стимдек, вообще говоря, можно тоже накатить любые эмуляторы, любые игры и любые программы (вплоть до винды, лол). У меня, например, сейчас там стоят такие ланчеры: сам стим, хероик (GoG), близзардовский (дьябла4 идет отлично, да), и еще чет для майнкрафта, чтоб у мсфт покупать.
И это все работает _в достаточной мере_ изкоробки (по правде говоря, по меркам десктопного линукса, в феноменальной мере это все работает само, а не из под палки)
nit: в тексте ошибки лучше писать что вы делали, а не то, что сломалось, потому что потом после нескольких обертываний получится длинная простыня стенаний: "failed X: error doing Y: cannot Z: ….”
А то что это ошибка в принципе понятно из логлевела, например.
Для тестирования под нагрузкой есть нагрузочное тестирование.
Для тестирования взаимодействия с инфраструктурой и соседними сервисами есть стейджинг, который, в идеале, и должен быть вторым продакшеном по архитектуре и вообще всему, кроме размера.
Деплоить каждый раз как в неизвестность - мне, например, здоровья уже не хватит :)
Дело не в спешке, а в рутинизации. Чем более у вас рутинизирован и безопасен процесс деплоя, тем меньше вероятность того, что когда нужен будет срочный хотфикс, вы все не разломаете до состояния "хуже чем было".
Вот этот майндсет «деплой - это проблема» и отравляет мне жизнь уже почти десять лет, не говоря уже обо всей индустрии. Не должен он быть ей, а если есть, то надо это чинить.
Так у вас система может в любой момент сломаться и без деплоев, для этого и есть онколл, не так ли?
А если факт деплоя заметно повышает вероятность сбоя, то, видимо, что-то не так с качеством и/или процессами. В таком случае инженерам будет хороший стимул исправить проблему, чтобы их онколл был спокойнее :)
Всегда это твердил всем вокруг, вот какой-то добрый человек написал нормальную статью.
Если вы боитесь деплоить по пятницам и перед праздниками, то стоит ли вам деплоить вообще, без уверенности что вы (или, лучше, автоматика) вовремя обнаружите и быстро откатите любую проблему?
Вряд ли атмосфера распухнет до высоты ГСО, где находится подавляющее большинство телекоммуникационных спутников.
Старлинк - может быть, но если он перестанет работать, всемирной катастрофы все-таки не произойдет
Это уже филиал ".баного айти" или еще нет?
"Загорелая снежинка", "лид начал ныть". Я думаю, если б автор текста не ушел сам, топнув ножкой, то его надо было бы все равно гнать обратно в ту помойку, где так принято общаться.
Нигде не спрятана, это потенциальная энергия железки в поле магнита. Когда железка прилепляется, она переходит в кинетическую, а когда вы ее отлепляете, то совершаете работу в этом поле.
Точно так же у вас самих есть запас потенциальной энергии в, например, гравитационном поле Луны.
Спасибо за ссылку. Посмотрел мельком на апи - лонг поллинг для грпц, как по мне, странная идея, если есть стримы.
И, что интересно, я специально искал все возможные варианты подобных опенсорсных штук прежде чем пилить свою - и не нашел вот это проект, хотя ключевые слова абсолютно совпадают.
Хе-хе, в понедельник я анонсировал (внутри конторы) GA своего сервиса-прокси кафки с грпц стримингом и протобафом, а сейчас эта статья.
Только у меня консьюмеры забирают сообщения из промежуточного батча в прокси, и коммитит оффсеты она же.
Буферизированные каналы - в 95% пахнущий кусок кода, который требует убедительного обоснования
Утверждение правильное, но я бы сказал, что опасное, особенно для новичков - надо очень хорошо понимать ref/spec и ref/mem чтобы знать, где можно (например, с доступом по индексам), а где нельзя (например, append)
Стоит отметить, что это не настоящие квантили, а приблизительно вычисленные из гистограммы, и чем меньше бакетов, тем меньше точность. Честно и эффективно считать квантили на потоковых данных - это та еще задачка, к которой пром, кажется, и не подступался, в отличие от, например, m3db.
Я б сказал, что для визуализации гистограмм больше подходят хитмапы, они вам и покажут именно то, что хранится, у них и плотность информации больше (видно не только латенси, но и ее распределение). Но читать их, конечно, сложнее.
Теперь актерам придется воображать не только окружение, но и освещение
На стимдек, вообще говоря, можно тоже накатить любые эмуляторы, любые игры и любые программы (вплоть до винды, лол).
У меня, например, сейчас там стоят такие ланчеры: сам стим, хероик (GoG), близзардовский (дьябла4 идет отлично, да), и еще чет для майнкрафта, чтоб у мсфт покупать.
И это все работает _в достаточной мере_ изкоробки (по правде говоря, по меркам десктопного линукса, в феноменальной мере это все работает само, а не из под палки)
nit: в тексте ошибки лучше писать что вы делали, а не то, что сломалось, потому что потом после нескольких обертываний получится длинная простыня стенаний: "failed X: error doing Y: cannot Z: ….”
А то что это ошибка в принципе понятно из логлевела, например.
The mere fact that you need to backup of kafka topic means you are likely doing something wrong with it.
What is the use case, I wonder? Tbh I only can imagine one use case - when you are using schema registry that stores schemas in kafka.
Для тестирования под нагрузкой есть нагрузочное тестирование.
Для тестирования взаимодействия с инфраструктурой и соседними сервисами есть стейджинг, который, в идеале, и должен быть вторым продакшеном по архитектуре и вообще всему, кроме размера.
Деплоить каждый раз как в неизвестность - мне, например, здоровья уже не хватит :)
Дело не в спешке, а в рутинизации. Чем более у вас рутинизирован и безопасен процесс деплоя, тем меньше вероятность того, что когда нужен будет срочный хотфикс, вы все не разломаете до состояния "хуже чем было".
Вот этот майндсет «деплой - это проблема» и отравляет мне жизнь уже почти десять лет, не говоря уже обо всей индустрии. Не должен он быть ей, а если есть, то надо это чинить.
Так у вас система может в любой момент сломаться и без деплоев, для этого и есть онколл, не так ли?
А если факт деплоя заметно повышает вероятность сбоя, то, видимо, что-то не так с качеством и/или процессами. В таком случае инженерам будет хороший стимул исправить проблему, чтобы их онколл был спокойнее :)
Всегда это твердил всем вокруг, вот какой-то добрый человек написал нормальную статью.
Если вы боитесь деплоить по пятницам и перед праздниками, то стоит ли вам деплоить вообще, без уверенности что вы (или, лучше, автоматика) вовремя обнаружите и быстро откатите любую проблему?
Это типичная задача на кодинг интервью, у нее нет цели, только путь
Это уже было в СССР (поищите ЦПС на страничке).
Оценка эффективности этой идеи автором весьма предсказуема
И совершенно правильно
ускоренное созревание кузнеца или столяра через промежуточную форму программиста