У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Конечно, никто ничего не запрещает, и всегда можно натянуть сову на глобус при большом желании. Вот только в MVC модель обновляет View, а в Delphi (как я его запомнил) ничего подобного не было. Были обработчики событий (Control) экранных элементов, в которых происходило и изменение View и изменение анемичных Model.
Ещё раз, я расстался с Delphi году в 2012. В ту пору его авторы начали дрейф в сторону CLR и Delphi Pascal, как ещё одного CLI-языка. Поэтому рассказываю, как оно было в то время. Структура формы была не заточена под MVC или любой другой осознанный шаблон. Собственно в то время кроме MVC и MVP никто ни о чём не слышал. Подход, который продавали вместе с Delphi был — RAD. Что это за зверь, и как структурировался код в 90% проектов, я рассказал. Кстати, серверной разработки на Delphi не было в принципе, а под клиент-серверными решениями подразумевалось desktop-приложение, в качестве клиента, и какой-нибудь Sybase или MS SQL Server, в качестве сервера.
Я не знаю, что там сейчас использует Delphi, и живо ли оно вообще. Я с ним работал с 1-ой по 7-ую версии. Тогда там никаким MVC ещё не пахло. У тебя была форма, которую ты набирал из компонентов в визуальном редакторе, у тебя были события, связанные с компонентами, и у тебя были обработчики этих событий. Главный рекламируемый паттерн Delphi в те времена был "х** х** и в продакшен", который по вумному тогда назывался RAD (rapid application development). То есть верхом разработки было поместить весь или почти весь код в обработчики этих событий. В одном обработчике можно было найти и работу с экранными элементами, и запросы к базе данных, и вычислительные алгоритмы, и всё остальное прочее (хотя это "прочее" в те времена не блистало разнообразием).
Так вот про MVC почти никто в те времена не задумывался. По крайней мере статей в профильных (бумажных) журналах про шаблоны проектирования и прочую теорию в те времена особо-то и не было. Ко всему прочему Delphi Pascal, хотя и имел в своём составе интерфейсы, так необходимые практически для каждого шаблона проектирования, но их реализация оставляла желать лучшего. В библиотеках и примерах кода они просто не использовались, а многие программисты на Delphi даже в теории не знали про их существование.
К чему это я? А к тому, что любая рефлексия того, что каждый из нас делает каждый день, очень важна и полезна для профессионального роста каждого из нас. Поэтому меня и не радует отношение "все эти ваши паттерны-шматерны, принципы, подходы, никому не нужны!". Подобное отношение приводит в пределе к RAD. Или иными словами спаггети-коду, говнокоду.
Лучше задумываться над тем, что и как ты делаешь, и тогда ты растёшь, чем упрощать всё до эмоциональных аргументов и анекдотов и топтаться на месте.
Вас понял, но у нас, действительно, разное понимание этого термина Э. Вы о продукте, я о размере организации и принципах управления такими организациями, а также количестве денег и возможностях, которые эти ресурсы дают ей. В Э-организациях есть разные продукты и проекты. Последние 10-20 лет, например, стали популярны внутренние стартапы. Э-организации разные бывают. Я работал в тех, которые "наелись" коробками и аутсорсом, проблемами и большими расходами, которые с ними связаны, и, в итоге, пришли к экономической целесообразности внутренней разработки. Однако, поскольку это их непрофильная деятельность, в них есть масса проблем, которые я описал в первом своём ответе. С другой стороны, Касперский, например, изначально создавался на написание коробок, но также представляет собой Э-организацию в силу своего размера и мирового масштаба. Хочешь не хочешь, а приходится внедрять иерархию и привлекать сторонних менеджеров, что даёт те же "болезни", что и, скажем, в МТС или ВТБ. В Яндексе и Озоне пока не работал, сказать точно, что там внутри творится не могу, но могу точно сказать, что HR-ы и процесс отбора там отстойный, поскольку многолетний опыт эпизодического общения с ними я уже имею.
Нет. Тем более, что это обобщённый опыт за последние 10-15 лет и несколько компаний. Да, разумеется вещи вроде сервера БД покупаются, а не разрабатываются самостоятельно, но софт, например, система автоматизации кредитования крупных компаний, разрабатывается самостоятельно, а не покупается коробкой/сервисом, хотя переговоры с подобными поставщиками ведутся в познавательных интересах.
У нас с Вами, видимо, просто разный опыт и понимание терминов. Для меня энетерпрайз это, например, Сбер, X5, Билайн, РБК, любой коммерческий банк, Касперский и т.д. Это не инди, не стартап, не Рога и копыта со своей конфигурацией 1С и т.п.
Какие примеры энетерпрайза в Вашем понимании этого термина Вы можете назвать?
Я бы, скорее, у названных проектов выделил общую черту, что это чисто коммерческие проекты/продукты/сервисы без особого внимания регуляторов, как у банков и мобильных провайдеров. К сожалению, WB и X5 мне точно не подходят, так как знаю их подноготную от бывших своих подчинённых. Сбер тоже к таким компаниям относится весьма двойственно. Ни плюшек материнской компании, ни свободы действий, и "давай-давай-давай". Да и в принципе я не ищу сейчас работу, меня устраивает место, где я работаю.
Не поймете меня неправильно. Даже подчёркивая проблемы энтерпрайза и других компаний, я отдаю себе отчёт, что они как-то выживают и даже приносят прибыль, несмотря на весь "песок" в своих механизмах. За 30 лет я привык к подобным вещам и просто стараюсь трезво оценивать действительность, что и где возможно, а что нет.
Ну, фиг его знает, у меня на проекте вполне себе чистая архитектура, привнесённая в запущенный проект мной. Новая часть кода сделана по ЧиА, а старая постепенно переносится из дремучего легаси в новую парадигму. Да, получилось много классов, но они маленькие, сконцентрированные на своей задаче, разбитые по слоям. Но в чём проблема? Так или иначе этот код должен был где-то быть, его было бы не меньше, но без ЧиА в легаси это большие классы на несколько сотен строк, а в новом коде это много классов до сотни строк каждый. Сборок тоже много, но это уже шаблон для новых модулей и разработчики привыкли подглядывать, в имеющиеся модули, чтобы понимать, какие сборки им сделать в новом модуле, что в них помещать, а что нет. То есть система работает, код писать и поддерживать проще, так как есть предсказуемость и системный подход. Да, мне пришлось поработать сверхурочно 2-3 месяца, но мне было интересно. Да, это модульный монолит, но это было сознательное решение и желательное изменение.
Смысл MVVM тоже прекрасно понятен, хотя в последних нескольких проектах я его не использую, так как разработка у меня серверная, а не desktop/mobile, как было раньше. Очень удобный шаблон, когда у вас есть возможность навесить bindings, как это, например, в WPF. И Ильичи, будь то Владимиры или Леониды, тут ни при чём. Или вы предлагает использовать подходы RAD времён Delphi и WinForms?
Эм, а это куда? :) Если серьёзно, что Вы под "инди" понимаете? Инди-игры я знаю, но их разработка, это скорее стартап на коленке в нерабочее время. Или иначе pet-project.
Я про энерпрайз и в Вашем понимании. Свои внутренние продукты, а от сторонних аутсорс, коробок и т.п. давно уже отказались. И я не про одно место, а про несколько в последние годы. Например, средний банк или сотовый провайдер большой тройки.
Не стартапами едиными... В энетерпрайзе всё тоже весьма плохо, в том числе и с чистой архитектурой.
Засилье эффективных менеджеров, ничего не понимающих в разработке, но имеющих своё мнение, которое они вынуждены демонстрировать, чтобы быть успешными. Правда, такая чайка живёт обычно недолго. Нагадит здесь, летит в другое место повторять успешный опыт. Отрицательный отбор. Рыба гниёт с головы.
Низкое качество требований. Отчасти из-за той же некомпетентности менеджеров, которые не знают, как работает их часть бизнеса, не говоря уже о смежных частях. Отчасти из-за недооценки и загруженности функциональных сотрудников, которые коллективно много знают, но не имеют права голоса и времени, чтобы донести своё видение. Отчасти из-за проблем с аналитиками, которые гордо называют себя системными, но на деле не могут справиться даже со сбором и фиксацией бизнес-требований.
Большое количество формализма в принятии решения, бюрократия. Слишком много откровенно лишних телодвижений, необходимых для доведения в прод чего бы то ни было.
Большое количество систем, сервисов и команд их создающих. Сложно договориться даже о простейшей интеграции между двумя смежными системами. Нет общих подходов и архитектуры всей информационной инфраструктуры компании (мозаичность решений).
Люди башни из слоновой кости, которые не могут даже пояснить за стрелки на их диаграммах, потоки данных это или зависимости.
Feature rush, но это свойственно любому бизнесу и было сказано про стартапы. Но в случае кровавого энетерпрайза это накладывается на все прочие проблемы.
Множество ограничений по доступным технологиям. "Я понимаю, что здесь лучше подойдёт MongoDB, но у нас можно только MS SQL Server или Oracle". Подставьте любые другие технологии.
Часто проблемы с инфраструктурой. Она большая, множество legacy оборудования, которое нужно подружить с более новым. Что-то постоянно падает.
Куча проблем, связанных с безопасностью. Тебе постоянно что-то запрещают. От тебя требуют каких-то странных вещей, например, резко дерзко закрывают доступ в репозиторий пакетов и требуют, чтобы ты дал полный список пакетов, к которым тебе необходим доступ. Любая дырка в файрволе может превратиться в недели согласований, а потом выясняется, что нужно ещё парочку проковырять и пробросить их через другие VLAN.
И как альфа и омега всего этого звездеца — всё те же эффективные менеджеры. Они повсюду и у каждого из них свой глюк.
С моей точки зрения, во всех компаниях, где я работал, а работал я много где, этот перформанс менеджмент — суть бюрократизация процесса оценки результативности сотрудников, основанная не на понятных ключевых показателях, а на консолидации мнений разных участников общего процесса.
Плюс к этому вот эти вот все разговоры, что линейный сотрудник должен проследить, всю цепочку от целей/ценностей/экономических показателей компании до выполнения его конкретных действий и обратно влияния его действий на достижение целей компании, в пользу бедных. Это просто невозможно сделать в большинстве случаев простому программисту или сисадмину. Для примера. Я вижу, что нужно выполнить рефакторинг некоторого куска кода (его размер зависит от моей компетентности или уровня). Должен ли я его сделать, если у компании есть следующие ценности: открытость, человечность, простота, инновации (взято с сайта Лаборатории Касперского, где я когда-то работал несколько лет)? Вот как я должен принять решение из этих абстракций? В какую категорию запихнуть мой рефакторинг? А если он одной ценности соответствует, а другой противоречит. По крайней мере в моём понимании. Да, я знаю, что мне скажут. Из ценностей выводятся цели, потом из тех ещё что-то и т.д. Вот только между этой пирамидой абстракций и конкретными действиями меня, как линейного сотрудника есть огромный понятийный разрыв, и принять решение относительно конкретных действий на основе пирамиды абстракций и благопожеланий "стратегов" компании просто невозможно. По крайней мере такое решение, которое будет оценено однозначно всеми/большинством сотрудниками.
Вся эта корпоративная культура, сиречь корпоративная религия, и прогрессивные HR-практики, были просто заимствованы с Запада, благодаря усилиям многочисленным тренерам оттуда и выходам на IPO, а где-то просто из желания не быть, а казаться. Ну все мы помним, кто постарше, истерию ISO 9000 и иже с ним. И где они? Ау?!
В итоге в наших условиях наших шпинатов всё это выродилось в кормушку разросшихся HR-отделов, которые не пойми чем занимаются, но только не быстрым и эффективным поиском новых сотрудников, что от них ждут большинство руководителей, которым эти сотрудники нужны ещё вчера. Говорю вам как человек, который в трёх компаниях работал в роли техлида/тимлида. Не работает вся эта пижня, по крайней мере в наших условиях.
Когда дело доходит до повышения зарплат или увольнения сотрудника, лучше всего работает "произвол" непосредственного начальника, который единственный может более-менее точно сказать от кого больше пользы, а от кого меньше.
И толку-то от того, что она выдаст ошибку, когда у вас место закончится? Вы логи постоянно читаете? Успеете среагировать?
Для мониторинга состояния оборудования, ресурсов и софта есть специальные инструменты для мониторинга, а для них дэшборды с красивыми, понятными индикаторами, графиками, алертами.
Чтобы дорасти, нужно удержаться. Чтобы удержаться, нужно правильно выбрать организацию, где не будет слишком скучно, и где не будут "выжимать" и "выдавливать". В каких организациях больше шансов на это, с Вашей точки зрения?
А что, собственно, делать таким талантливым людям? Куда и на какие должности устраиваться, с Вашей точки зрения? Архитектор? В большинстве мест архитектор — это человек из башни слоновой кости, который мало что понимает о продуктах, которые он пытается интегрировать в единое целое (они часто даже не могут объяснить, что обозначают стрелочки на их диаграммах: зависимости или потоки данных). Техлид? Техлид чаще всего — это "сбалансированная должность", как сказала одна девочка-HR, которая, скорее, "разбалансированная" в силу обилия задач, которые сваливают на такого специалиста. Наставник? Таких должностей нет. Системный аналитик? Это точно не про "меньше общаться с людьми и расти в архитектора". Сеньор-разработчик? Ну, Вы только что забанили такой вариант своей статьёй. Так на кого подаваться "золотой шестерёнке" и куда?
cert-manager не умеет работать в связке с ExternalDNS. Его нет в списке интеграций, но есть до сих пор открытое issue на тему интеграции.
Из этого issue я узнал, что ExternalDNS не умеет работать с TXT записями (только A и CNAME): issue.
Концепция ExternalDNS, если я понял её правильно, состоит в следующем: у вас есть сайты, которые нужно выставить наружу, вам лень (или сайтов очень много) прописывать для них DNS-записи руками, вы ставите ExternalDNS, который сканирует ваши ingress-ресурсы, берёт из них адреса сайтов и создаёт для них DNS-записи. Эта проблема (автоматическое создание DNS-записей) находится вне рамок данной статьи. Более того, задача как раз не публиковать в публичную Сеть внутренние сайты (тогда можно было бы вообще HTTP-01 обойтись). Даже если считать, что DNS-записи будут создаваться во внутреннем DNS, всё равно это не является темой данной статьи.
В целом, да, ExternalDNS — не бесполезный проект, можно найти ему применение, но к теме статьи имеет лишь косвенное отношение.
Я кратко ознакомился с его описанием по Вашей наводке, но не понял, как его можно использовать для решения моей проблемы? Можете прокомментировать более подробно свою мысль?
SP больше предназначены для организации диалога команды о реализации задачи, чем для сбора реальной статистики и итоговой оценки времени реализации задачи в часах/днях. Во время покера не интересны средние оценки, интересны крайние оценки. Один говорит: 1, другой 100500. Вот это интересно, так как тот, кто оценивает задачу простой, может знать о уже реализованном функционале ("немного допилим и переиспользуем"), второй знает о каких-то траблах, о которых никто другой не в курсе ("нам там интегрироваться нужно с продуктом Х, а у них неделю назад ушёл последний разработчик, есть только менеджер, который ещё на испытательном и не набрал экспертизы").
А так, в целом, согласен. Из гибких подходов разработки слепили религию Agile с массой сект, вроде Scrum, и священниками в лице скрам-мастеров и им подобных, многие из которых ни строчки кода не написали (был у нас один такой диджей с радио, Антон, привет!)
Каждому своё. Лишь бы Вам нравилось, и деньги достаточные платили.
У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Перепутал я год. Правильно, в 2005 я с Delphi закончил и перешёл на C#. Старый уже, память плохая. :) Как раз .NET Framework 3 вышел.
А RAD хорош только для маленьких короткоживущих проектов. Для остальных проектов — это ад. Никому не пожелаю в таких участвовать.
Конечно, никто ничего не запрещает, и всегда можно натянуть сову на глобус при большом желании. Вот только в MVC модель обновляет View, а в Delphi (как я его запомнил) ничего подобного не было. Были обработчики событий (Control) экранных элементов, в которых происходило и изменение View и изменение анемичных Model.
Ещё раз, я расстался с Delphi году в 2012. В ту пору его авторы начали дрейф в сторону CLR и Delphi Pascal, как ещё одного CLI-языка. Поэтому рассказываю, как оно было в то время. Структура формы была не заточена под MVC или любой другой осознанный шаблон. Собственно в то время кроме MVC и MVP никто ни о чём не слышал. Подход, который продавали вместе с Delphi был — RAD. Что это за зверь, и как структурировался код в 90% проектов, я рассказал. Кстати, серверной разработки на Delphi не было в принципе, а под клиент-серверными решениями подразумевалось desktop-приложение, в качестве клиента, и какой-нибудь Sybase или MS SQL Server, в качестве сервера.
Я не знаю, что там сейчас использует Delphi, и живо ли оно вообще. Я с ним работал с 1-ой по 7-ую версии. Тогда там никаким MVC ещё не пахло. У тебя была форма, которую ты набирал из компонентов в визуальном редакторе, у тебя были события, связанные с компонентами, и у тебя были обработчики этих событий. Главный рекламируемый паттерн Delphi в те времена был "х** х** и в продакшен", который по вумному тогда назывался RAD (rapid application development). То есть верхом разработки было поместить весь или почти весь код в обработчики этих событий. В одном обработчике можно было найти и работу с экранными элементами, и запросы к базе данных, и вычислительные алгоритмы, и всё остальное прочее (хотя это "прочее" в те времена не блистало разнообразием).
Так вот про MVC почти никто в те времена не задумывался. По крайней мере статей в профильных (бумажных) журналах про шаблоны проектирования и прочую теорию в те времена особо-то и не было. Ко всему прочему Delphi Pascal, хотя и имел в своём составе интерфейсы, так необходимые практически для каждого шаблона проектирования, но их реализация оставляла желать лучшего. В библиотеках и примерах кода они просто не использовались, а многие программисты на Delphi даже в теории не знали про их существование.
К чему это я? А к тому, что любая рефлексия того, что каждый из нас делает каждый день, очень важна и полезна для профессионального роста каждого из нас. Поэтому меня и не радует отношение "все эти ваши паттерны-шматерны, принципы, подходы, никому не нужны!". Подобное отношение приводит в пределе к RAD. Или иными словами спаггети-коду, говнокоду.
Лучше задумываться над тем, что и как ты делаешь, и тогда ты растёшь, чем упрощать всё до эмоциональных аргументов и анекдотов и топтаться на месте.
Вас понял, но у нас, действительно, разное понимание этого термина Э. Вы о продукте, я о размере организации и принципах управления такими организациями, а также количестве денег и возможностях, которые эти ресурсы дают ей. В Э-организациях есть разные продукты и проекты. Последние 10-20 лет, например, стали популярны внутренние стартапы. Э-организации разные бывают. Я работал в тех, которые "наелись" коробками и аутсорсом, проблемами и большими расходами, которые с ними связаны, и, в итоге, пришли к экономической целесообразности внутренней разработки. Однако, поскольку это их непрофильная деятельность, в них есть масса проблем, которые я описал в первом своём ответе. С другой стороны, Касперский, например, изначально создавался на написание коробок, но также представляет собой Э-организацию в силу своего размера и мирового масштаба. Хочешь не хочешь, а приходится внедрять иерархию и привлекать сторонних менеджеров, что даёт те же "болезни", что и, скажем, в МТС или ВТБ. В Яндексе и Озоне пока не работал, сказать точно, что там внутри творится не могу, но могу точно сказать, что HR-ы и процесс отбора там отстойный, поскольку многолетний опыт эпизодического общения с ними я уже имею.
Нет. Тем более, что это обобщённый опыт за последние 10-15 лет и несколько компаний. Да, разумеется вещи вроде сервера БД покупаются, а не разрабатываются самостоятельно, но софт, например, система автоматизации кредитования крупных компаний, разрабатывается самостоятельно, а не покупается коробкой/сервисом, хотя переговоры с подобными поставщиками ведутся в познавательных интересах.
У нас с Вами, видимо, просто разный опыт и понимание терминов. Для меня энетерпрайз это, например, Сбер, X5, Билайн, РБК, любой коммерческий банк, Касперский и т.д. Это не инди, не стартап, не Рога и копыта со своей конфигурацией 1С и т.п.
Какие примеры энетерпрайза в Вашем понимании этого термина Вы можете назвать?
Я бы, скорее, у названных проектов выделил общую черту, что это чисто коммерческие проекты/продукты/сервисы без особого внимания регуляторов, как у банков и мобильных провайдеров. К сожалению, WB и X5 мне точно не подходят, так как знаю их подноготную от бывших своих подчинённых. Сбер тоже к таким компаниям относится весьма двойственно. Ни плюшек материнской компании, ни свободы действий, и "давай-давай-давай". Да и в принципе я не ищу сейчас работу, меня устраивает место, где я работаю.
Не поймете меня неправильно. Даже подчёркивая проблемы энтерпрайза и других компаний, я отдаю себе отчёт, что они как-то выживают и даже приносят прибыль, несмотря на весь "песок" в своих механизмах. За 30 лет я привык к подобным вещам и просто стараюсь трезво оценивать действительность, что и где возможно, а что нет.
Ну, фиг его знает, у меня на проекте вполне себе чистая архитектура, привнесённая в запущенный проект мной. Новая часть кода сделана по ЧиА, а старая постепенно переносится из дремучего легаси в новую парадигму. Да, получилось много классов, но они маленькие, сконцентрированные на своей задаче, разбитые по слоям. Но в чём проблема? Так или иначе этот код должен был где-то быть, его было бы не меньше, но без ЧиА в легаси это большие классы на несколько сотен строк, а в новом коде это много классов до сотни строк каждый. Сборок тоже много, но это уже шаблон для новых модулей и разработчики привыкли подглядывать, в имеющиеся модули, чтобы понимать, какие сборки им сделать в новом модуле, что в них помещать, а что нет. То есть система работает, код писать и поддерживать проще, так как есть предсказуемость и системный подход. Да, мне пришлось поработать сверхурочно 2-3 месяца, но мне было интересно. Да, это модульный монолит, но это было сознательное решение и желательное изменение.
Смысл MVVM тоже прекрасно понятен, хотя в последних нескольких проектах я его не использую, так как разработка у меня серверная, а не desktop/mobile, как было раньше. Очень удобный шаблон, когда у вас есть возможность навесить bindings, как это, например, в WPF. И Ильичи, будь то Владимиры или Леониды, тут ни при чём. Или вы предлагает использовать подходы RAD времён Delphi и WinForms?
Эм, а это куда? :) Если серьёзно, что Вы под "инди" понимаете? Инди-игры я знаю, но их разработка, это скорее стартап на коленке в нерабочее время. Или иначе pet-project.
Я про энерпрайз и в Вашем понимании. Свои внутренние продукты, а от сторонних аутсорс, коробок и т.п. давно уже отказались. И я не про одно место, а про несколько в последние годы. Например, средний банк или сотовый провайдер большой тройки.
Не стартапами едиными... В энетерпрайзе всё тоже весьма плохо, в том числе и с чистой архитектурой.
Засилье эффективных менеджеров, ничего не понимающих в разработке, но имеющих своё мнение, которое они вынуждены демонстрировать, чтобы быть успешными. Правда, такая чайка живёт обычно недолго. Нагадит здесь, летит в другое место повторять успешный опыт. Отрицательный отбор. Рыба гниёт с головы.
Низкое качество требований. Отчасти из-за той же некомпетентности менеджеров, которые не знают, как работает их часть бизнеса, не говоря уже о смежных частях. Отчасти из-за недооценки и загруженности функциональных сотрудников, которые коллективно много знают, но не имеют права голоса и времени, чтобы донести своё видение. Отчасти из-за проблем с аналитиками, которые гордо называют себя системными, но на деле не могут справиться даже со сбором и фиксацией бизнес-требований.
Большое количество формализма в принятии решения, бюрократия. Слишком много откровенно лишних телодвижений, необходимых для доведения в прод чего бы то ни было.
Большое количество систем, сервисов и команд их создающих. Сложно договориться даже о простейшей интеграции между двумя смежными системами. Нет общих подходов и архитектуры всей информационной инфраструктуры компании (мозаичность решений).
Люди башни из слоновой кости, которые не могут даже пояснить за стрелки на их диаграммах, потоки данных это или зависимости.
Feature rush, но это свойственно любому бизнесу и было сказано про стартапы. Но в случае кровавого энетерпрайза это накладывается на все прочие проблемы.
Множество ограничений по доступным технологиям. "Я понимаю, что здесь лучше подойдёт MongoDB, но у нас можно только MS SQL Server или Oracle". Подставьте любые другие технологии.
Часто проблемы с инфраструктурой. Она большая, множество legacy оборудования, которое нужно подружить с более новым. Что-то постоянно падает.
Куча проблем, связанных с безопасностью. Тебе постоянно что-то запрещают. От тебя требуют каких-то странных вещей, например, резко дерзко закрывают доступ в репозиторий пакетов и требуют, чтобы ты дал полный список пакетов, к которым тебе необходим доступ. Любая дырка в файрволе может превратиться в недели согласований, а потом выясняется, что нужно ещё парочку проковырять и пробросить их через другие VLAN.
И как альфа и омега всего этого звездеца — всё те же эффективные менеджеры. Они повсюду и у каждого из них свой глюк.
Толку-то учить этот HR? У них там та же текучка кадров. Круговорот эффективных менеджеров в природе-с.
С моей точки зрения, во всех компаниях, где я работал, а работал я много где, этот перформанс менеджмент — суть бюрократизация процесса оценки результативности сотрудников, основанная не на понятных ключевых показателях, а на консолидации мнений разных участников общего процесса.
Плюс к этому вот эти вот все разговоры, что линейный сотрудник должен проследить, всю цепочку от целей/ценностей/экономических показателей компании до выполнения его конкретных действий и обратно влияния его действий на достижение целей компании, в пользу бедных. Это просто невозможно сделать в большинстве случаев простому программисту или сисадмину. Для примера. Я вижу, что нужно выполнить рефакторинг некоторого куска кода (его размер зависит от моей компетентности или уровня). Должен ли я его сделать, если у компании есть следующие ценности: открытость, человечность, простота, инновации (взято с сайта Лаборатории Касперского, где я когда-то работал несколько лет)? Вот как я должен принять решение из этих абстракций? В какую категорию запихнуть мой рефакторинг? А если он одной ценности соответствует, а другой противоречит. По крайней мере в моём понимании. Да, я знаю, что мне скажут. Из ценностей выводятся цели, потом из тех ещё что-то и т.д. Вот только между этой пирамидой абстракций и конкретными действиями меня, как линейного сотрудника есть огромный понятийный разрыв, и принять решение относительно конкретных действий на основе пирамиды абстракций и благопожеланий "стратегов" компании просто невозможно. По крайней мере такое решение, которое будет оценено однозначно всеми/большинством сотрудниками.
Вся эта корпоративная культура, сиречь корпоративная религия, и прогрессивные HR-практики, были просто заимствованы с Запада, благодаря усилиям многочисленным тренерам оттуда и выходам на IPO, а где-то просто из желания не быть, а казаться. Ну все мы помним, кто постарше, истерию ISO 9000 и иже с ним. И где они? Ау?!
В итоге в наших условиях наших шпинатов всё это выродилось в кормушку разросшихся HR-отделов, которые не пойми чем занимаются, но только не быстрым и эффективным поиском новых сотрудников, что от них ждут большинство руководителей, которым эти сотрудники нужны ещё вчера. Говорю вам как человек, который в трёх компаниях работал в роли техлида/тимлида. Не работает вся эта пижня, по крайней мере в наших условиях.
Когда дело доходит до повышения зарплат или увольнения сотрудника, лучше всего работает "произвол" непосредственного начальника, который единственный может более-менее точно сказать от кого больше пользы, а от кого меньше.
И толку-то от того, что она выдаст ошибку, когда у вас место закончится? Вы логи постоянно читаете? Успеете среагировать?
Для мониторинга состояния оборудования, ресурсов и софта есть специальные инструменты для мониторинга, а для них дэшборды с красивыми, понятными индикаторами, графиками, алертами.
Чтобы дорасти, нужно удержаться. Чтобы удержаться, нужно правильно выбрать организацию, где не будет слишком скучно, и где не будут "выжимать" и "выдавливать". В каких организациях больше шансов на это, с Вашей точки зрения?
А что, собственно, делать таким талантливым людям? Куда и на какие должности устраиваться, с Вашей точки зрения?
Архитектор? В большинстве мест архитектор — это человек из башни слоновой кости, который мало что понимает о продуктах, которые он пытается интегрировать в единое целое (они часто даже не могут объяснить, что обозначают стрелочки на их диаграммах: зависимости или потоки данных). Техлид? Техлид чаще всего — это "сбалансированная должность", как сказала одна девочка-HR, которая, скорее, "разбалансированная" в силу обилия задач, которые сваливают на такого специалиста. Наставник? Таких должностей нет. Системный аналитик? Это точно не про "меньше общаться с людьми и расти в архитектора". Сеньор-разработчик? Ну, Вы только что забанили такой вариант своей статьёй.
Так на кого подаваться "золотой шестерёнке" и куда?
Скорее всего, Вы неправы.
cert-manager не умеет работать в связке с ExternalDNS. Его нет в списке интеграций, но есть до сих пор открытое issue на тему интеграции.
Из этого issue я узнал, что ExternalDNS не умеет работать с TXT записями (только A и CNAME): issue.
Концепция ExternalDNS, если я понял её правильно, состоит в следующем: у вас есть сайты, которые нужно выставить наружу, вам лень (или сайтов очень много) прописывать для них DNS-записи руками, вы ставите ExternalDNS, который сканирует ваши ingress-ресурсы, берёт из них адреса сайтов и создаёт для них DNS-записи. Эта проблема (автоматическое создание DNS-записей) находится вне рамок данной статьи. Более того, задача как раз не публиковать в публичную Сеть внутренние сайты (тогда можно было бы вообще HTTP-01 обойтись). Даже если считать, что DNS-записи будут создаваться во внутреннем DNS, всё равно это не является темой данной статьи.
В целом, да, ExternalDNS — не бесполезный проект, можно найти ему применение, но к теме статьи имеет лишь косвенное отношение.
Я кратко ознакомился с его описанием по Вашей наводке, но не понял, как его можно использовать для решения моей проблемы? Можете прокомментировать более подробно свою мысль?
SP больше предназначены для организации диалога команды о реализации задачи, чем для сбора реальной статистики и итоговой оценки времени реализации задачи в часах/днях. Во время покера не интересны средние оценки, интересны крайние оценки. Один говорит: 1, другой 100500. Вот это интересно, так как тот, кто оценивает задачу простой, может знать о уже реализованном функционале ("немного допилим и переиспользуем"), второй знает о каких-то траблах, о которых никто другой не в курсе ("нам там интегрироваться нужно с продуктом Х, а у них неделю назад ушёл последний разработчик, есть только менеджер, который ещё на испытательном и не набрал экспертизы").
А так, в целом, согласен. Из гибких подходов разработки слепили религию Agile с массой сект, вроде Scrum, и священниками в лице скрам-мастеров и им подобных, многие из которых ни строчки кода не написали (был у нас один такой диджей с радио, Антон, привет!)