Да, согласен насчёт дополнительного otherwise в choice для ошибки.
Endpoint DSL выглядит очень интересно, спасибо.
Насчёт использования - подробно не могу раскрыть ответ, просто на одном коммерческом проекте столкнулся с использованием Apache Camel. И пока просто интересно его изучать.
Современные игровые ноутбуку продуваются довольно хорошо. Охлаждающая подставка дает понижение температуры на грани погрешности. В случае старого макбука про речь идёт о плохой продувке корпуса вкупе с металлом в качестве материала корпуса. Поэтому в случае мака охлаждающая подставка могла давать видимые результаты.
В районе 1998 года компьютер и игровой компьютер сейчас - совсем разные вещи в вопросе того же веса. Двубашенный кулер или СВО, видеокарта на 2-3 вентилятора с массивным радиатором, толстостенный корпус - всё это слабо способствует переноске корпуса, и это только корпуса. А ещё монитор и другая периферия.
Да и к тому же полный набор настольного ПК (с монитором и клавомышью) вряд ли поместиться в ручную кладь в самолете.
Под показателями я имел ввиду вычислительную мощность. Монитор дело наживное, а вот RTX видеокарты в моём городе были немногим дешевле чем игровой ноутбук.
В каких-то случах я согласен что это удобнее. Но отвечу чуть подробнее по каждому из предложных кейсов.
eGPU + ультрабук - связка довольно хорошая, если есть более-менее постоянное рабочее место и играть (работать) только там. Вот только с точки зрения мобильности хуже игрового ноутбука (т.к. это блок питания eGPU + сам кейс с карточкой внутри + ультрабук + блок к нему - ни по весу ни по габаритам даже не близко к игровому ноутбуку).
ульрабук + RDP для работы - требуется и наличие соединения и его неплохое качество (речь не про скорость скорее а про стабильность). Что не всегда может быть доступно.
В сравнении с ультрабуками у игровых ноутбуков весьма сомнительная мобильность, так и есть. В сравнении с десктопами очень даже хорошая. Как раз промежуточная ниша, компромисс. В последнее время это ещё был и едва ли не самый дешевый способ получить игровой компьютер с хорошими показателями.
Вполне может сработать. Похоже я упустил момент в статье. Задача которая стояла передо мной была в том чтобы выставить метрики по адресу /actuator/prometheus и именно в формате для сбора внешним prometheus сервисом.
Если я правильно понял то HealthIndicator выставит JSON и для сбора его прометеусом надо будет делать трансляцию?
Только что попробовал сделать у себя в тестовом проекте так как вы и описали - без объявленного моим способом PrometheusMeterRegistry не срабатывает.
Даже частичного срабатывания (когда метрики есть по адресу /actuator/metrics но не попадают или не обновляются в /actuator/prometheus) у меня не происходит.
Существует ещё пока не прикрытая юридическая лавочка как откосить от этого самого распределения, если человеку остался хотя бы один семестр до диплома. Но, похоже, про неё мало кто знает. Сам пользовался.
Солидарен. Очень давно и долгое время пользовался закладками, выкладывал красивую структуру, бекапил и прочее. И в какой-то момент времени понял что почти вся коллекция не нужна.
Используемые вкладки множатся во время работы над сложной или незнакомой задачей, но так же закрываются после решения этой задачи.
А если надо что-то из видео-сериалов глянуть или прочитать - то разные вариации "смотреть позже" помогают на захламлять браузер.
Зависит от команды. Иногда это бывает предельно начальникоцентрировано. Иногда достаточно какого-нибудь инициативного бизнес-аналитика или тестировщика чтобы уже некоторая часть документации находилась в таком состоянии, когда её наличие побуждает других людей добавлять новые вещи.
Проблемы начинаются там, где программистов в первый год разработки только гонят по срокам реализации новых фич, а потом, через год, начинают спрашивать «а почему так много багов?», «а почему все так тормозит?» и у программистов, почему-то, не хватает смелости сказать очевидную вещь: а что хотели, то и получили!
Подписываюсь. По моему опыту заказчикам на первых этапах разработки очень сложно решиться разменять время разработчиков на более качественную работу. Работу с требованиями, работу над разработкой решения которое будет не таким лобовым и тормознутым. Конечно, со стороны заказчиков тоже есть причины, по которым они и делают этот выбор. Но это удивление, в определенный период жизни проекта, когда вылезают минусы принятого раннее решения — выглядит по-детски.
Позволю себе похулиганить и дать симметричный ответ в виде причин не танцевать танго по категориям:
Фронтендщики — нужно думать о балансе, шаге, собирать танец по кусочкам. Люди могут приходить на милонги в чем бог на душу положит.
Тестировщики — можно закопаться в багах партнеров. При большом акценте на своих багах может отпасть желание танцевать.
Бекенд — можно забыть как ходить в повседневной жизни. Желания партнеров поукрашаться могут сбивать с толку. На какие-нибудь знаменательные даты все бывает такое пёстрое…
ДевОпс — постоянно играясь со сборками новых техник можно остаться в стороне от людей. Постоянно быть в поиске того кто готов разделить эксперименты.
Проджект менеджер — можно столкнуться что люди не заходят играть по твоим правилам. Кто-то отвалился и не пришел на нужную практиу, милонгу, занятие, семинар и т.д. И даже самое простое, в случае ведущего — партнёр не идёт куда хочется, не делает что ожидается и т.д.
Знакомая ситуация, очень знакомая. Все-таки первоначальный интерес, который хоть немного переломит нежелание оказываться среди других людей, нужен чтобы дойти аж до танцев.
Я приходил в танго с мыслью о том что мне нужна какая-то активность, которой до этого не было. Спорт и боевые искусства уже были раньше. Поэтому подумал про танцы, сразу пришла мысль про танго и понеслось — нашел школу, пробное занятие т.д.
Добавлю еще это — www.youtube.com/watch?v=wd5xaPT2I9M. После этого видео я отбросил сомнения в стиле «у меня нет данных» и записался на первое занятие.
Да, согласен насчёт дополнительного otherwise в choice для ошибки.
Endpoint DSL выглядит очень интересно, спасибо.
Насчёт использования - подробно не могу раскрыть ответ, просто на одном коммерческом проекте столкнулся с использованием Apache Camel. И пока просто интересно его изучать.
Современные игровые ноутбуку продуваются довольно хорошо. Охлаждающая подставка дает понижение температуры на грани погрешности. В случае старого макбука про речь идёт о плохой продувке корпуса вкупе с металлом в качестве материала корпуса. Поэтому в случае мака охлаждающая подставка могла давать видимые результаты.
В районе 1998 года компьютер и игровой компьютер сейчас - совсем разные вещи в вопросе того же веса. Двубашенный кулер или СВО, видеокарта на 2-3 вентилятора с массивным радиатором, толстостенный корпус - всё это слабо способствует переноске корпуса, и это только корпуса. А ещё монитор и другая периферия.
Да и к тому же полный набор настольного ПК (с монитором и клавомышью) вряд ли поместиться в ручную кладь в самолете.
Под показателями я имел ввиду вычислительную мощность. Монитор дело наживное, а вот RTX видеокарты в моём городе были немногим дешевле чем игровой ноутбук.
В каких-то случах я согласен что это удобнее. Но отвечу чуть подробнее по каждому из предложных кейсов.
eGPU + ультрабук - связка довольно хорошая, если есть более-менее постоянное рабочее место и играть (работать) только там. Вот только с точки зрения мобильности хуже игрового ноутбука (т.к. это блок питания eGPU + сам кейс с карточкой внутри + ультрабук + блок к нему - ни по весу ни по габаритам даже не близко к игровому ноутбуку).
ульрабук + RDP для работы - требуется и наличие соединения и его неплохое качество (речь не про скорость скорее а про стабильность). Что не всегда может быть доступно.
Люди разные, кейсы разные.
В сравнении с ультрабуками у игровых ноутбуков весьма сомнительная мобильность, так и есть. В сравнении с десктопами очень даже хорошая. Как раз промежуточная ниша, компромисс. В последнее время это ещё был и едва ли не самый дешевый способ получить игровой компьютер с хорошими показателями.
Вполне может сработать. Похоже я упустил момент в статье. Задача которая стояла передо мной была в том чтобы выставить метрики по адресу /actuator/prometheus и именно в формате для сбора внешним prometheus сервисом.
Если я правильно понял то HealthIndicator выставит JSON и для сбора его прометеусом надо будет делать трансляцию?
К сожалению готового ответа у меня нет.
Только что попробовал сделать у себя в тестовом проекте так как вы и описали - без объявленного моим способом PrometheusMeterRegistry не срабатывает.
Даже частичного срабатывания (когда метрики есть по адресу /actuator/metrics но не попадают или не обновляются в /actuator/prometheus) у меня не происходит.
Существует ещё пока не прикрытая юридическая лавочка как откосить от этого самого распределения, если человеку остался хотя бы один семестр до диплома. Но, похоже, про неё мало кто знает. Сам пользовался.
Солидарен. Очень давно и долгое время пользовался закладками, выкладывал красивую структуру, бекапил и прочее. И в какой-то момент времени понял что почти вся коллекция не нужна.
Используемые вкладки множатся во время работы над сложной или незнакомой задачей, но так же закрываются после решения этой задачи.
А если надо что-то из видео-сериалов глянуть или прочитать - то разные вариации "смотреть позже" помогают на захламлять браузер.
В этом случае на помощь приходит дублирование систем. Ошибки в одной из систем перекрываются штатной работой других.
Версия с поддержкой v3 сейчас в альфе.
Подписываюсь. По моему опыту заказчикам на первых этапах разработки очень сложно решиться разменять время разработчиков на более качественную работу. Работу с требованиями, работу над разработкой решения которое будет не таким лобовым и тормознутым. Конечно, со стороны заказчиков тоже есть причины, по которым они и делают этот выбор. Но это удивление, в определенный период жизни проекта, когда вылезают минусы принятого раннее решения — выглядит по-детски.
Фронтендщики — нужно думать о балансе, шаге, собирать танец по кусочкам. Люди могут приходить на милонги в чем бог на душу положит.
Тестировщики — можно закопаться в багах партнеров. При большом акценте на своих багах может отпасть желание танцевать.
Бекенд — можно забыть как ходить в повседневной жизни. Желания партнеров поукрашаться могут сбивать с толку. На какие-нибудь знаменательные даты все бывает такое пёстрое…
ДевОпс — постоянно играясь со сборками новых техник можно остаться в стороне от людей. Постоянно быть в поиске того кто готов разделить эксперименты.
Проджект менеджер — можно столкнуться что люди не заходят играть по твоим правилам. Кто-то отвалился и не пришел на нужную практиу, милонгу, занятие, семинар и т.д. И даже самое простое, в случае ведущего — партнёр не идёт куда хочется, не делает что ожидается и т.д.
To be continued :)
Я приходил в танго с мыслью о том что мне нужна какая-то активность, которой до этого не было. Спорт и боевые искусства уже были раньше. Поэтому подумал про танцы, сразу пришла мысль про танго и понеслось — нашел школу, пробное занятие т.д.