Мне для подобного очень помогла связка emacs+vim-плагин и org-mode. Org-mode даёт быстро вставляемые шаблоны заметок/дневниковых записей/итогов периода, а vim-плагин помогает отмечать или не отмечать чекбоксики в самоопросниках простым нажатием '.' в связке с 'j', который переходит к следующей строке. Ну и всё это под gpg и внутри git, т.е. нет никакой зависимости ни от операционной системы, ни от коммерческой компании.
Не исключено, что это нужно для госов и окологосов и их интеграторов. Международные сертификации больше не доступны, а внутренний ответ на "конкурс требует наличия у исполнителя не менее N сертифицированных специалистов по M" такая сертификация даёт. Ну и в госкомпаниях это может быть частью системы требований к должностям. однако прокторинг пока отсутствует и потому ценности в такой оценке сейчас мало: отвечать на вопросы может вообще другой человек.
Вы точно честно сравниваете между собой стоимость инсталляции Оракла с его сертифицированным под него железом и стоимость решения на Постгрессах поверх чего попалось, где дельту можно смело вложить в Департамент Разработки Великолепных Решений и не остаться в накладе по итогу?
Посмотрел ссылки. Никакого подтверждения тезису, что на одной и той же железке джоин пары таблиц с фуллсканом оракл будет делать на два порядка быстрее постгресса не увидел. Увидел обсуждение неких специфичных конкретных кейсов, которых может просто не существовать в куче мест и которые в случае возникновения решаемы самим владельцем сервиса несколькими разными способами.
Я как-то всё по крупным компаниям обретаюсь и обычно везде C-level назначал владельца DevOps-экосистемы и продуктовые менеджеры вполне могли обсуждать с ним потребное взаимодействие, в случае необходимости эскалируя.
Вам нужна не инфра, а возможности для релизов, тестирования и эксплуатации. Вот именно они и являются темой для обсуждения с DevOps-командой. А уж как они там работают внутри оставьте инфраструктурщиками и их коммунальным решениям
По опыту вот эти вот быстрые проверки на продах регулярно становятся причиной авралов, потому и реакция такая: все регулярно бьют себя пяткой в грудь "да ничего страшного, я сто раз так дома на ноуте делал" и оно регулярно же от такого сыпется из-за разных неучтённых моментов и банального человеческого фактора. Отдайте ответственность за доступность вашего прода вашему командному девопсу и тогда вы сами сможете управлять рисками и подобными тестами. Но хорошей практикой является выстраивание отлаженной цепочки релизов DEV->UAT->PROD, которую вы в любой момент можете быстро прогнать: тогда у вас сохраняется управляемость и появляется скорость.
продуктовый менеджер не должен уметь в инфраструктуру: его задача быстро разрабатывать и катить продукт, ценный бизнесу. А для технических знаний есть отдельные технические люди
уверен, что каждый, кто приходил к стоматологу с идеями как поставить себе титановые челюсти для разгрызания тросов знает, какие эти стоматологи негодяи и токсики
менеджеры обычно неплохо понимают язык денег, когда фичи оцениваются деньгами на выбор: тогда они сами бегают и выбивают бюджеты или смиряются. Поэтому умение аллоцировать стоимость ресурсов на проекты часто здорово облегчает коммуникации после прохождения менеджерами этапа принятия.
Резануло глаз, поэтому позволю себе заметить, что DevOps, тот самый, который не человек, а методология, это больше всего про общение и совместное непрерывное нанесение ценностей работодателю и его пользователям, а не цепочка "должен, должен, должен", обёрнутая в ITIL с согласованными сроками рассмотрения.
Узкое место в том, что коммунальная инфраструктура должна строиться с учётом интересов всех команд и быть максимально гомогенной, прозрачной и управляемой и нужно хорошо в ней разбираться, чтобы переделывать и развивать её адекватным способом. Если просто дать рули разработчикам отдельных продуктов, то обычно она очень быстро потеряет все эти 3 качества, в том числе разделившись на много слабосовместимых контуров с разными подходами и технологиями. И по моему скромному опыту проблема усугубляется тем, что среднее время жизни разработчика на проекте около 1,5 лет и участники изменений из команд достаточно быстро меняются, а весь техдолг остаётся, накапливаясь. Как в переписке правильно заметили, часть девопсовой ответственности должна включать релизы продуктов, чтобы они не окукливались в обеспечении стабильности инфры и прикладов, каковая проще всего достигается остановкой изменений.
Действительно здесь махровая проблема с процессами и зонами ответственности. Как по мне, это частично лечится переведом части девопсов в продуктивные команды, чтобы поменять их приоритеты на командоориентированные, оставив пару на платформе. Тогда они уже сами между собой договорятся в интересах продуктов и платформы. Но да, сверху должен быть тот, кто будет смазывать их общение и не даст перетянуть одеяло на себя ни одной из сторон
Аргумент про то, что прерывания рвут поток и тяжело вспомнить разбиваются о эффект Зейгарник, который о том, что мозг лучше всего запоминает незавершённые задачи.
Лично мне метод Помодоро очень помогает фокусироваться на главном в текущий момент. У меня во время него включается системный режим "не беспокоить" и звук тикания часов и это мне инженеру очень помогает не утопить день в переписках и общении.
Мне для подобного очень помогла связка emacs+vim-плагин и org-mode. Org-mode даёт быстро вставляемые шаблоны заметок/дневниковых записей/итогов периода, а vim-плагин помогает отмечать или не отмечать чекбоксики в самоопросниках простым нажатием '.' в связке с 'j', который переходит к следующей строке. Ну и всё это под gpg и внутри git, т.е. нет никакой зависимости ни от операционной системы, ни от коммерческой компании.
Не исключено, что это нужно для госов и окологосов и их интеграторов. Международные сертификации больше не доступны, а внутренний ответ на "конкурс требует наличия у исполнителя не менее N сертифицированных специалистов по M" такая сертификация даёт. Ну и в госкомпаниях это может быть частью системы требований к должностям. однако прокторинг пока отсутствует и потому ценности в такой оценке сейчас мало: отвечать на вопросы может вообще другой человек.
Вы точно честно сравниваете между собой стоимость инсталляции Оракла с его сертифицированным под него железом и стоимость решения на Постгрессах поверх чего попалось, где дельту можно смело вложить в Департамент Разработки Великолепных Решений и не остаться в накладе по итогу?
Посмотрел ссылки. Никакого подтверждения тезису, что на одной и той же железке джоин пары таблиц с фуллсканом оракл будет делать на два порядка быстрее постгресса не увидел. Увидел обсуждение неких специфичных конкретных кейсов, которых может просто не существовать в куче мест и которые в случае возникновения решаемы самим владельцем сервиса несколькими разными способами.
Я как-то всё по крупным компаниям обретаюсь и обычно везде C-level назначал владельца DevOps-экосистемы и продуктовые менеджеры вполне могли обсуждать с ним потребное взаимодействие, в случае необходимости эскалируя.
Вам нужна не инфра, а возможности для релизов, тестирования и эксплуатации. Вот именно они и являются темой для обсуждения с DevOps-командой. А уж как они там работают внутри оставьте инфраструктурщиками и их коммунальным решениям
при том, что менеджеры бывают всякие, а Вы их всех в своём комментарии уравняли и потребовали от них техскиллов инженеров инфраструктуры
а сможете пруфы привести?
По опыту вот эти вот быстрые проверки на продах регулярно становятся причиной авралов, потому и реакция такая: все регулярно бьют себя пяткой в грудь "да ничего страшного, я сто раз так дома на ноуте делал" и оно регулярно же от такого сыпется из-за разных неучтённых моментов и банального человеческого фактора. Отдайте ответственность за доступность вашего прода вашему командному девопсу и тогда вы сами сможете управлять рисками и подобными тестами. Но хорошей практикой является выстраивание отлаженной цепочки релизов DEV->UAT->PROD, которую вы в любой момент можете быстро прогнать: тогда у вас сохраняется управляемость и появляется скорость.
продуктовый менеджер не должен уметь в инфраструктуру: его задача быстро разрабатывать и катить продукт, ценный бизнесу. А для технических знаний есть отдельные технические люди
уверен, что каждый, кто приходил к стоматологу с идеями как поставить себе титановые челюсти для разгрызания тросов знает, какие эти стоматологи негодяи и токсики
менеджеры обычно неплохо понимают язык денег, когда фичи оцениваются деньгами на выбор: тогда они сами бегают и выбивают бюджеты или смиряются. Поэтому умение аллоцировать стоимость ресурсов на проекты часто здорово облегчает коммуникации после прохождения менеджерами этапа принятия.
Резануло глаз, поэтому позволю себе заметить, что DevOps, тот самый, который не человек, а методология, это больше всего про общение и совместное непрерывное нанесение ценностей работодателю и его пользователям, а не цепочка "должен, должен, должен", обёрнутая в ITIL с согласованными сроками рассмотрения.
Узкое место в том, что коммунальная инфраструктура должна строиться с учётом интересов всех команд и быть максимально гомогенной, прозрачной и управляемой и нужно хорошо в ней разбираться, чтобы переделывать и развивать её адекватным способом. Если просто дать рули разработчикам отдельных продуктов, то обычно она очень быстро потеряет все эти 3 качества, в том числе разделившись на много слабосовместимых контуров с разными подходами и технологиями. И по моему скромному опыту проблема усугубляется тем, что среднее время жизни разработчика на проекте около 1,5 лет и участники изменений из команд достаточно быстро меняются, а весь техдолг остаётся, накапливаясь. Как в переписке правильно заметили, часть девопсовой ответственности должна включать релизы продуктов, чтобы они не окукливались в обеспечении стабильности инфры и прикладов, каковая проще всего достигается остановкой изменений.
Действительно здесь махровая проблема с процессами и зонами ответственности. Как по мне, это частично лечится переведом части девопсов в продуктивные команды, чтобы поменять их приоритеты на командоориентированные, оставив пару на платформе. Тогда они уже сами между собой договорятся в интересах продуктов и платформы. Но да, сверху должен быть тот, кто будет смазывать их общение и не даст перетянуть одеяло на себя ни одной из сторон
Аргумент про то, что прерывания рвут поток и тяжело вспомнить разбиваются о эффект Зейгарник, который о том, что мозг лучше всего запоминает незавершённые задачи.
Лично мне метод Помодоро очень помогает фокусироваться на главном в текущий момент. У меня во время него включается системный режим "не беспокоить" и звук тикания часов и это мне инженеру очень помогает не утопить день в переписках и общении.
чтобы свич с линуксом подключить в поездке к внешнему телевизору или монитору, с ним надо тащить его огромную докстанцию?
про что и речь
если таскать портативный монитор, то macbook air уделает такую мобильность по всем фронтам, включая полноценность софта и железа
NAT это именно защита, но от случаев, когда защита не от провайдера. Защиты обычно эшелонированные и это просто один из эшелонов.