Предложенное в статье больше похоже на фантазии дилетанта в области найма. Этакая зелёная девочка хэар переносит свой опыт выбора жениха на собеседование с разработчиками.
Перед собеседованием можно добавить этап выполнения тестового задания. Хорошее тестовое задание должно быть максимально приближено к реальным задачам. Чтобы оценить навыки, можно предложить что-то объёмное, например, разработку небольшого, но полнофункционального сервиса. Важно, чтобы кандидат сделал всё самостоятельно и в кратчайшие сроки — это покажет, насколько он заинтересован в позиции. Если человек отказывается от тестового задания, это говорит о недостаточной вовлечённости.
Вот ищу я работу. У меня, скажем, 10 вариантов. Если каждый из них будет давать мне тестовое задание, да ещё и приближенное к реальным задачам... Ясно видно, что наша девочка никогда не программировала и не понимает, сколько это занимает времени. Я про реальные задачи, а не пузырьковая сортировка. Я лично от тестовых заданий всегда отказываюсь. Если настаивают, отправляю в свой гитхаб, там моего кода много, есть даже специально выполненные тестовые задания. Смотрите, оценивайте. На бесплатное заказное программирование я время, а значит и деньги, тратить не собираюсь.
Что значит "заинтересован в позиции"? Да откуда я знаю, как оно там у вас на самом деле в компании? Как там у вас там с условиями, ЗП, задачами? Почитать на сайте? Так там такие же зелёные девочки из маркетинга пишут сами не зная чего, пересыпая этот бред всяким булшитом, вроде "лидер отрасли", "ведущая компания" и т.п. Я лично всегда с известной долей настороженности отношусь к любой позиции и компании. Как там оно на самом деле у вас для меня только вскрытие покажет.
Вовлечённость? Куда? Мы ещё не познакомились, я у вас не поработал. Откуда вовлечённости взяться? Вы кто такие, чтобы я вам что-то о себе доказывал?
Сколько человек должно проводить собеседование? Оптимально 3-5. Один интервьюер может что-то упустить, а вот группа сможет задать вопросы с разных точек зрения.
Девочка, видимо, ещё не знает сколько стоит час разработчика, и сколько встреч у менеджера. Тем более это заметно, когда кандидатов поток. По-хорошему должен собеседовать только тимлид.
Дайте ему посидеть в зуме или в офисе минут 10–15, чтобы он смог привыкнуть к обстановке, успокоиться и морально подготовиться. В реальной работе нередко приходится ждать ответа коллег или заказчиков, и умение сохранять самообладание в таких ситуациях — важное качество.
10-15 минут на разогрев? Это не разогрев называется, а маринование, уважаемый кулинар. Не надо женские приёмы со свиданий распространять на деловые переговоры. Это плохой тон. Вы собираетесь сожрать мои 10-15 минут без видимой причины, это неуважение.
Один из самых показательных вопросов на собеседовании — «Почему вы хотите работать именно у нас?». Задайте его первым. Он позволяет сразу определить, насколько кандидат заинтересован в компании, изучил ли он её заранее и готов ли искренне обосновать свой выбор. Если кандидату важны только деньги, то вы быстро сможете это определить и закончить разговор не потратив впустую час‑два времени.
Про заинтересованность писал выше. Ей неоткуда ещё появиться.
У меня 10 вакансий на руках, я заинтересован в них почти одинаково, так как реальной информации не хватает. Только работа в компании и конкретной команде может показать, что вы собой представляете. Могу ещё один вопрос посоветовать: "с каким животным вы себя ассоциируете?" Он ещё более гениальный, особенно в самом начале собеседования.
Затем переходите к вопросам, о самом человеке. Наличие детей, семейное положение, планы на ближайшие годы — всё это влияет на мотивацию сотрудника и его стабильность в компании.
А на каком основании вы собрались мне задавать личные вопросы? Опять неуважение к кандидату.
Существует две стратегии задавания технических вопросов.
Это вообще шедевр. Однозначно правильные ответы можно получить только на простые вопросы. Проблема с простыми шаблонными вопросами в том, что ответы на них зазубривают. Даже не зная почти ничего по теме, человек легко пройдёт этот этап. Были у меня такие на собеседованиях. Со сложными вопросами, нельзя дать однозначный правильный вопрос, нужно задавать дополнительные вопросы. В конце концов, важно не то, как человек проходит "профессиональный ЕГЭ-угадайку", а его аналитические возможности, умение находить информацию, умение воплотить идею в код, а не вот эти ваши тесты.
Переработки, давление, дедлайны? Вот точно в такую компанию не пойду, хоть и работаю по собственной инициативе (просто самому интересно) по 10-12 часов в день. Зачем мне соковыжиматель? Мне работа нужна, где мне будет интересно, обеспечено и комфортно. Привыкли к людям как к тряпкам относиться? Тогда мне точно с вами не по пути. Прозябайте дальше и умрите, как компания!
После прохождения всех этапов важно не торопиться с ответом. Подождите неделю, две, а лучше три, чтобы кандидат прочувствовал всю значимость решения. Заодно это позволит проверить, насколько он заинтересован: если начнёт писать и спрашивать, значит, действительно хочет работать в вашей компании. Важно создать ощущение, что кандидат должен доказать свою ценность, а не наоборот.
А ещё лучше вообще не давайте ответа, пусть приползёт к вашему офису и просидит под дождём неделю без пищи и только на воде из атмосферных осадков. Зарплату от должен будет платить вам, а не вы ему. С женой пусть разведётся, квартиру подарит вам, научиться раболепно улыбаться и заискивать, пусть благодарит до пенсии за возможность "поработать" в подобной компании. Ах, да, и пусть в 6 утра каждый день, включая выходные и отпуск, поёт гимн компании, высоко, гордо задрав голову к динамику в потолке офисной комнаты вместе со всей командой.
Короче, автор, ты бредишь. Лично я, столкнувшись с тобой на собеседовании, послал бы тебя по известному адресу. Уйди из найма! И коллег своих подобных забери с собой! Вы слишком глупы для IT.
У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Конечно, никто ничего не запрещает, и всегда можно натянуть сову на глобус при большом желании. Вот только в 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, которая, скорее, "разбалансированная" в силу обилия задач, которые сваливают на такого специалиста. Наставник? Таких должностей нет. Системный аналитик? Это точно не про "меньше общаться с людьми и расти в архитектора". Сеньор-разработчик? Ну, Вы только что забанили такой вариант своей статьёй. Так на кого подаваться "золотой шестерёнке" и куда?
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, и священниками в лице скрам-мастеров и им подобных, многие из которых ни строчки кода не написали (был у нас один такой диджей с радио, Антон, привет!)
А почему Вы решили, что это шуточная статья? Я лично не нашёл никаких предупреждений об этом. 1 апреля тоже далеко.
Предложенное в статье больше похоже на фантазии дилетанта в области найма. Этакая зелёная девочка хэар переносит свой опыт выбора жениха на собеседование с разработчиками.
Вот ищу я работу. У меня, скажем, 10 вариантов. Если каждый из них будет давать мне тестовое задание, да ещё и приближенное к реальным задачам... Ясно видно, что наша девочка никогда не программировала и не понимает, сколько это занимает времени. Я про реальные задачи, а не пузырьковая сортировка. Я лично от тестовых заданий всегда отказываюсь. Если настаивают, отправляю в свой гитхаб, там моего кода много, есть даже специально выполненные тестовые задания. Смотрите, оценивайте. На бесплатное заказное программирование я время, а значит и деньги, тратить не собираюсь.
Что значит "заинтересован в позиции"? Да откуда я знаю, как оно там у вас на самом деле в компании? Как там у вас там с условиями, ЗП, задачами? Почитать на сайте? Так там такие же зелёные девочки из маркетинга пишут сами не зная чего, пересыпая этот бред всяким булшитом, вроде "лидер отрасли", "ведущая компания" и т.п. Я лично всегда с известной долей настороженности отношусь к любой позиции и компании. Как там оно на самом деле у вас для меня только вскрытие покажет.
Вовлечённость? Куда? Мы ещё не познакомились, я у вас не поработал. Откуда вовлечённости взяться? Вы кто такие, чтобы я вам что-то о себе доказывал?
Девочка, видимо, ещё не знает сколько стоит час разработчика, и сколько встреч у менеджера. Тем более это заметно, когда кандидатов поток. По-хорошему должен собеседовать только тимлид.
10-15 минут на разогрев? Это не разогрев называется, а маринование, уважаемый кулинар. Не надо женские приёмы со свиданий распространять на деловые переговоры. Это плохой тон. Вы собираетесь сожрать мои 10-15 минут без видимой причины, это неуважение.
Про заинтересованность писал выше. Ей неоткуда ещё появиться.
У меня 10 вакансий на руках, я заинтересован в них почти одинаково, так как реальной информации не хватает. Только работа в компании и конкретной команде может показать, что вы собой представляете. Могу ещё один вопрос посоветовать: "с каким животным вы себя ассоциируете?" Он ещё более гениальный, особенно в самом начале собеседования.
А на каком основании вы собрались мне задавать личные вопросы? Опять неуважение к кандидату.
Это вообще шедевр. Однозначно правильные ответы можно получить только на простые вопросы. Проблема с простыми шаблонными вопросами в том, что ответы на них зазубривают. Даже не зная почти ничего по теме, человек легко пройдёт этот этап. Были у меня такие на собеседованиях. Со сложными вопросами, нельзя дать однозначный правильный вопрос, нужно задавать дополнительные вопросы. В конце концов, важно не то, как человек проходит "профессиональный ЕГЭ-угадайку", а его аналитические возможности, умение находить информацию, умение воплотить идею в код, а не вот эти ваши тесты.
Переработки, давление, дедлайны? Вот точно в такую компанию не пойду, хоть и работаю по собственной инициативе (просто самому интересно) по 10-12 часов в день. Зачем мне соковыжиматель? Мне работа нужна, где мне будет интересно, обеспечено и комфортно. Привыкли к людям как к тряпкам относиться? Тогда мне точно с вами не по пути. Прозябайте дальше и умрите, как компания!
А ещё лучше вообще не давайте ответа, пусть приползёт к вашему офису и просидит под дождём неделю без пищи и только на воде из атмосферных осадков. Зарплату от должен будет платить вам, а не вы ему. С женой пусть разведётся, квартиру подарит вам, научиться раболепно улыбаться и заискивать, пусть благодарит до пенсии за возможность "поработать" в подобной компании. Ах, да, и пусть в 6 утра каждый день, включая выходные и отпуск, поёт гимн компании, высоко, гордо задрав голову к динамику в потолке офисной комнаты вместе со всей командой.
Короче, автор, ты бредишь. Лично я, столкнувшись с тобой на собеседовании, послал бы тебя по известному адресу. Уйди из найма! И коллег своих подобных забери с собой! Вы слишком глупы для IT.
Каждому своё. Лишь бы Вам нравилось, и деньги достаточные платили.
У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Перепутал я год. Правильно, в 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, которая, скорее, "разбалансированная" в силу обилия задач, которые сваливают на такого специалиста. Наставник? Таких должностей нет. Системный аналитик? Это точно не про "меньше общаться с людьми и расти в архитектора". Сеньор-разработчик? Ну, Вы только что забанили такой вариант своей статьёй.
Так на кого подаваться "золотой шестерёнке" и куда?
Скорее всего, Вы неправы.
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, и священниками в лице скрам-мастеров и им подобных, многие из которых ни строчки кода не написали (был у нас один такой диджей с радио, Антон, привет!)