я не провидец и не знаю, какие события будут критичными
Их легко определить. Критичные события - те, что вы хотели бы получать на email при их возникновении. Например, неперехваченное исключение, которое вылезло на самый верх и спровоцировало 500 ошибку. Или какая-нибудь специфическая ошибка при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован".
это пусть решают те, кто организуют телеметрию
Никто кроме программиста не знает что означает та или иная запись в логе. Впрочем, даже сами программисты зачастую теряют это знание спустя год-два после разработки. Своим безразличием вы просто добавляете лишней работы коллегам из "отдела телеметрии".
1. Гитлаб, по моему опыту, - самое беспроблемное приложение, не требующее особого ухода. По крайней мере в команде из 10 человек. Я трачу на его сопровождение всего 10 минут в неделю: делаю бэкап, скачиваю новую версию образа (если успела выйти) и перезапускаю на новом образе.
1.1. Ваше предложение не масштабируется. Придется переделывать, когда возникнет необходимость деплоить более чем на один сервер. Плюс есть проблемы с безопасностью - прод не должен иметь доступ к деву, а в вашей схеме потребуется пробить дырку из прода к гитлабу.
2. Встроенный container registry появился в 2016 году и сразу был доступен для всех. А вот package registry (maven, npm и прочие) был изначально платным, но переехал во free tier в 2020 году. Видимо, автор в 2015 настроил CI до состояния "работает - не трожь" и теперь делится хоть и готовым, но, увы, устаревшим рецептом. А может он поленился узнать какими фичами вообще обладает гитлаб. Или просто теряется в имеющейся документации (как он пишет в комментарии выше).
Сразу после публикации последнего отчета стоимость акций ASML упала всего на 4%.
А к концу торгового дня получилось -7%. На следующий день падение продолжилось. На текущий момент акции припали уже на -12%. Боюсь, негатив от отчёта ещё не до конца впитан рынком, поэтому падение будет продолжаться дальше.
все рекламные SMS составлены так, чтобы государственные надзорные органы в лице ФАС и РКН не смогли ничего предъявить за спам. Действия лиц по предварительному сговору?
То, как составлен текст смс, не имеет никакого значения. Достаточно только увидеть признаки рекламы в тексте, чтобы запустить машину. ФАС отправляет запрос оператору, оператор агрегатору, агрегатор своему клиенту, тот своему и так далее, пока запрос не дойдёт до конечного заказчика. Заказчик в ответ присылает согласие абонента, которое обратно по этой же цепочке возвращается в ФАС. Ну или не возвращается и тогда ФАС штрафует оператора, тот перекладывает штраф на агрегатора и так далее.
Опять же автоматически обновить зависимости можно, но не сломает ли это проект?
Сломает. Обязательно сломает. Если не сразу, то потом.
но у всех ли хорошо с тестами?
У кого плохо с тестами - тому renovate противопоказан.
И что же получается, если в проекте скажем пару сотен зависимостей, получается нужно выкатывать новый релиз через день, т.к. что-то где-то да обновится.
Можно и так конечно. А можно придерживаться своего обычного графика релизов.
При этом новая функциональность не добавляется, но риск словить непредвиденный баг и сломать сервис присутствует.
Проекты в конце своего жизненного цикла, всё ещё стоящие на поддержке, именно так и поддерживаются обычно. Регулярных обновлений требуют как минимум tzdata, ca сертификаты (характерно для проектов на java, но и на других языках тоже достаточно видел) и версия юникода/ICU.
Новая функциональность тоже может приехать. Например, поддержка очередной новой версии TLS.
Ну и конечно этот подход не годится для организаций, где релизный цикл хоть как-то регламентирован, и просто так катить обновление ради обновления не получится.
Так пусть катят согласно своему регламенту, а не при каждом обновлении зависимостей.
Коммит всегда будет выглядеть плохо на экранах и размерах меньших, чем принятое в команде ограничение. Коммит без ограничений будет выглядеть хорошо на любых размерах. Под спойлером я как раз привёл пример для сравнения.
Уж сколько видел рекомендаций по составлению идеальных коммитов, но нелепое правило 72 символов так и кочует от статьи к статье. Авторы этих текстов хоть сами пробовали сжать консоль до 72 символов или просто копипастят рекомендации не глядя? Я ещё могу понять такую рекомендацию во времена SVGA мониторов с резрешением 800х600 пикселей или в мире, где фичу с переносом слов ещё не изобрели.
Посмотреть на консоль шириной 72
В этом коммит мессадже длина строки не ограничена, но в консоли шириной 72 символа всё выглядит вполне прилично и читабельно.
Для сравнения, комментарий ниже следует какому-то ограничению (но не 72) и выглядит это явно хуже:
Но с ограничением длины первой строки согласен. Первая строка должна максимально кратко и ёмко описывать суть изменений. Чтобы при просмотре списка коммитов можно было быстро сориентироваться, не тратя время на прочтение полного текста каждого коммита. Разве что 50 символов - это чересчур мало.
Ещё кратко коснулись стиля angular, но об отдельном стандарте, выросшим из данного стиля, совсем ни слова. Всем рекомендую ознакомиться - https://www.conventionalcommits.org/
Когда у меня в компании покупали IPv4 блок, в нагрузку впарили ещё и IPv6 блок. Грубо говоря, LIR сказал: "без IPv6 не продадим вам IPv4". Раз уж IPv6 блок всё равно взяли, я упрашивал админов сделать тестовую IPv6 сетку, но каждый раз меня кормили завтраками и отговорками.
Дело сдвинулось с мёртвой точки только когда компания решила поучаствовать в тендере яндекса. В тендерной документации было обязательное требование - полная поддержка IPv6. Так как техническое взаимодействие предполагалось исключительно по этому протоколу.
К сожалению, с тендером не срослось и IPv6 я так и не увидел. Но яндекс молодец. Раскачивает это болото.
Пока не найдётся достаточно крупный новатор, который будет мотивировать других к внедрению IPv6, - не видать нам светлого будущего. Новатором, кстати, может быть и государственный регулятор.
Я с такой же целью купил Raspberry PI. В итоге после пары месяцев экспериментов и страданий заменил на Xiaomi Mi TV Stick, а RPI приспособил для другого. Так что на своём опыте советую присмотреться к готовым ТВ приставкам, а не к одноплатникам.
Ок, я согласен, что переход на другую базу не делается бесплатно и необходимо потратиться на переобучение имеющихся DBA. Но это всё CapEx, а не OpEx. Ещё мне непонятна ваша фраза "впоследствии повышать из зарплату до рынка, чтоб не сбежали". У DBA oracle/mssql отсутствует необходимость индексировать зарплату или что? Или сокращение инсталляций oracle/mssql не приводит к сокращению штата DBA этих баз (переобучением и переводом имеющегося штата на новую базу или увольнением и наймом новых)? Откуда берётся перекладывание зарплаты из ДИТ в HR?
Не очень понял как соотносится поддержка с лицензиями и упомянутым вами ФОТ. Это разные статьи расходов и сокращение одной не означает автоматическое увеличение остальных.
У среднего пользователя недостаточно квалификации чтобы понять это. Особенно если государство будет продвигать свой СА под соусом "государственной безопасности".
Да и необязательно заставлять пользователей делать это самостоятельно. Можно просто продавить микрософт, чтобы сертификат "государственной безопасности" прилетел в автоматическом обновлении всем гражданам данного государства. В таком случае пользователь уж точно не будет винить себя.
Их легко определить. Критичные события - те, что вы хотели бы получать на email при их возникновении. Например, неперехваченное исключение, которое вылезло на самый верх и спровоцировало 500 ошибку. Или какая-нибудь специфическая ошибка при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован".
Никто кроме программиста не знает что означает та или иная запись в логе. Впрочем, даже сами программисты зачастую теряют это знание спустя год-два после разработки. Своим безразличием вы просто добавляете лишней работы коллегам из "отдела телеметрии".
1. Гитлаб, по моему опыту, - самое беспроблемное приложение, не требующее особого ухода. По крайней мере в команде из 10 человек. Я трачу на его сопровождение всего 10 минут в неделю: делаю бэкап, скачиваю новую версию образа (если успела выйти) и перезапускаю на новом образе.
1.1. Ваше предложение не масштабируется. Придется переделывать, когда возникнет необходимость деплоить более чем на один сервер. Плюс есть проблемы с безопасностью - прод не должен иметь доступ к деву, а в вашей схеме потребуется пробить дырку из прода к гитлабу.
2. Встроенный container registry появился в 2016 году и сразу был доступен для всех. А вот package registry (maven, npm и прочие) был изначально платным, но переехал во free tier в 2020 году. Видимо, автор в 2015 настроил CI до состояния "работает - не трожь" и теперь делится хоть и готовым, но, увы, устаревшим рецептом. А может он поленился узнать какими фичами вообще обладает гитлаб. Или просто теряется в имеющейся документации (как он пишет в комментарии выше).
А к концу торгового дня получилось -7%. На следующий день падение продолжилось. На текущий момент акции припали уже на -12%. Боюсь, негатив от отчёта ещё не до конца впитан рынком, поэтому падение будет продолжаться дальше.
То, как составлен текст смс, не имеет никакого значения. Достаточно только увидеть признаки рекламы в тексте, чтобы запустить машину. ФАС отправляет запрос оператору, оператор агрегатору, агрегатор своему клиенту, тот своему и так далее, пока запрос не дойдёт до конечного заказчика. Заказчик в ответ присылает согласие абонента, которое обратно по этой же цепочке возвращается в ФАС. Ну или не возвращается и тогда ФАС штрафует оператора, тот перекладывает штраф на агрегатора и так далее.
Сломает. Обязательно сломает. Если не сразу, то потом.
У кого плохо с тестами - тому renovate противопоказан.
Можно и так конечно. А можно придерживаться своего обычного графика релизов.
Проекты в конце своего жизненного цикла, всё ещё стоящие на поддержке, именно так и поддерживаются обычно. Регулярных обновлений требуют как минимум tzdata, ca сертификаты (характерно для проектов на java, но и на других языках тоже достаточно видел) и версия юникода/ICU.
Новая функциональность тоже может приехать. Например, поддержка очередной новой версии TLS.
Так пусть катят согласно своему регламенту, а не при каждом обновлении зависимостей.
Prometheus работает по pull модели. То есть он сам ходит по сервисам и собирает с них метрики в удобном для себя темпе. Это точно не хайлоад.
И да, как и с графаной, хайлоадом это становится, когда "смотрят несколько тысяч человек единовременно (зачем?)".
Коммит всегда будет выглядеть плохо на экранах и размерах меньших, чем принятое в команде ограничение. Коммит без ограничений будет выглядеть хорошо на любых размерах. Под спойлером я как раз привёл пример для сравнения.
Уж сколько видел рекомендаций по составлению идеальных коммитов, но нелепое правило 72 символов так и кочует от статьи к статье. Авторы этих текстов хоть сами пробовали сжать консоль до 72 символов или просто копипастят рекомендации не глядя? Я ещё могу понять такую рекомендацию во времена SVGA мониторов с резрешением 800х600 пикселей или в мире, где фичу с переносом слов ещё не изобрели.
Посмотреть на консоль шириной 72
В этом коммит мессадже длина строки не ограничена, но в консоли шириной 72 символа всё выглядит вполне прилично и читабельно.
Для сравнения, комментарий ниже следует какому-то ограничению (но не 72) и выглядит это явно хуже:
Но с ограничением длины первой строки согласен. Первая строка должна максимально кратко и ёмко описывать суть изменений. Чтобы при просмотре списка коммитов можно было быстро сориентироваться, не тратя время на прочтение полного текста каждого коммита. Разве что 50 символов - это чересчур мало.
Ещё кратко коснулись стиля angular, но об отдельном стандарте, выросшим из данного стиля, совсем ни слова. Всем рекомендую ознакомиться - https://www.conventionalcommits.org/
Когда у меня в компании покупали IPv4 блок, в нагрузку впарили ещё и IPv6 блок. Грубо говоря, LIR сказал: "без IPv6 не продадим вам IPv4". Раз уж IPv6 блок всё равно взяли, я упрашивал админов сделать тестовую IPv6 сетку, но каждый раз меня кормили завтраками и отговорками.
Дело сдвинулось с мёртвой точки только когда компания решила поучаствовать в тендере яндекса. В тендерной документации было обязательное требование - полная поддержка IPv6. Так как техническое взаимодействие предполагалось исключительно по этому протоколу.
К сожалению, с тендером не срослось и IPv6 я так и не увидел. Но яндекс молодец. Раскачивает это болото.
Пока не найдётся достаточно крупный новатор, который будет мотивировать других к внедрению IPv6, - не видать нам светлого будущего. Новатором, кстати, может быть и государственный регулятор.
Теоретически да, так как у этого стика есть bluetooth и android tv поддерживает bluetooth клавиатуры. Но я на практике не проверял.
Я с такой же целью купил Raspberry PI. В итоге после пары месяцев экспериментов и страданий заменил на Xiaomi Mi TV Stick, а RPI приспособил для другого. Так что на своём опыте советую присмотреться к готовым ТВ приставкам, а не к одноплатникам.
5 секунд
Лучше не надо, так как это раскрывает состав кластера через публичные certificate transparency логи.
Эта "очень плохая" практика зафиксирована в международном стандарте PCI DSS:
Ок, я согласен, что переход на другую базу не делается бесплатно и необходимо потратиться на переобучение имеющихся DBA. Но это всё CapEx, а не OpEx. Ещё мне непонятна ваша фраза "впоследствии повышать из зарплату до рынка, чтоб не сбежали". У DBA oracle/mssql отсутствует необходимость индексировать зарплату или что? Или сокращение инсталляций oracle/mssql не приводит к сокращению штата DBA этих баз (переобучением и переводом имеющегося штата на новую базу или увольнением и наймом новых)? Откуда берётся перекладывание зарплаты из ДИТ в HR?
Не очень понял как соотносится поддержка с лицензиями и упомянутым вами ФОТ. Это разные статьи расходов и сокращение одной не означает автоматическое увеличение остальных.
По вашим словам складывается впечатление, будто DBA oracle и mssql предоставляются в аренду вендорами и входят в стоимость лицензий.
У среднего пользователя недостаточно квалификации чтобы понять это. Особенно если государство будет продвигать свой СА под соусом "государственной безопасности".
Да и необязательно заставлять пользователей делать это самостоятельно. Можно просто продавить микрософт, чтобы сертификат "государственной безопасности" прилетел в автоматическом обновлении всем гражданам данного государства. В таком случае пользователь уж точно не будет винить себя.
Да. Никаких проблем.