Проект скомпилируется и обосрется через 2 минуты инициализации контейнера
Да, есть di контейнеры, которые гарантируют консистентность на уровне компиляции, но это накладывает другие серьезные ограничения на них, которых у спринга нет. Выбирайте, что вам важнее.
… а тут пропертю забыли подсунуть в файл..
Звучит как «если вы взяли какую-то другую библиотеку, то она не падает в рантайме если ей забыли пропертю подсунуть в файл».
Ну т.е. на него таки вываливают всё это дерьмо сразу.
Нет, обычно проблемы появляются по одной, а если ваш код вообще не работает, то вряд ли стоит в этом винить спринг.
Еще как виноват..
То есть вы искреннее считаете, что тот факт, что вы не можете сделать большое приложение на спринге, означает, что никто не может? Я обсолютно согласен с тезисом, что если сложность фреймворка вас пугает, не надо его использовать. Возьмите что-то попроще, возможно ничего более сложного и не потребуется. Остальное можно и напедалить. Но не нужно винить в этом спринг — он лишь инструмент, которым вы или умеете пользоваться и получаете то, что нужно или нет. Лично для меня важно, что я могу воспользоваться готовыми решениями и их интеграцией из коробки, а не писать их заново. Конечно никакое решение не идеально в том числе и спринг, просто не нужно строить на этот счет иллюзий и выбирать инструмент по себе и своей задаче.
Еще хочу заметить, что спринг в первую очередь это система интеграции сторонних библиотек и решений, а не какие-то конкретные решения (хотя конечно и они есть), более того обычно ты можешь выбирать какие реализации ты будешь использовать и из коробки идет несколько. Я это к тому, что спринг не просто не исключает использования набора простых решений, но напротив именно к тому тебя и подталкивает и предоставляет удобные способы их интегрировать в приложение, многие прямо из коробки.
Спринг сам по себе решает ровно одну задачу. Интеграцию решений. Плюс у спринга еще есть много дополнительных библиотек, которые решают другие задачи. Тоже обычно по одному за раз.
т.е. разобраться с одним спрингом сложнее, чем с полусотней других «простых» решений? В спринге хотя бы всё более менее однообразно и всё работает из коробки, а набор «простых» решений еще придется друг к другу подгонять и писать интеграцию.
Дайте угадаю: если кто-то и ответил, то запросил настолько космических денег, что вы его не стали рассматривать.
Выше писал о том, что правильный ответ здесь не важен, к тому же его обычно никто не знает. И лично мне на денежные претензии кандидата глубоко плевать, потому что моя сфера — это исключительно его техническая компетенция.
1. Собеседование длится всего-то час или около того. Вам больше время некуда потратить?
У меня много способов потратить время, но если я провожу интервью, то я трачу время именно на это. Мне нужно максимально быстро получить представление о человеке как о специалисте и коллеге, а этот вопрос не только позволяет в редких случаях выявить человека, который разбирается в нужном мне стеке, но и дает огромное количество материала для обсуждения и понимания уровня кандидата. Лично меня вообще не интересует может ли кандидат засунуть квадратный люк в круглый колодец или знает ли он наизусть все методы SessionImplementor, на мой взгляд в первую очередь важны личные качества кандидата и как он себе представляет разработку, насколько он четко мыслит в этом направлении. Всё это можно выяснить начиная с этого вопроса.
2. Если разработчик ответил правильно — как этот ответ характеризует его как специалиста и профессионала?
Вопрос этот очень богат коннотациями, например, он позволяет посмотреть насколько человек представляет как работает язык: кто-то вообще не понимает в чем проблема передать в конструкторы двум классам друг друга. Показывает насколько человек глубоко знает спринг, потому что совершенно не обязательно знать правильный ответ на этот вопрос, чтобы предположить как спринг себя поведет в той или иной ситуации. Если же человек сразу отвечает, то скорее всего он человек прошаренный и можно много времени сэкономить. Опять же, я не требую правильного ответа на этот вопрос, а лишь считаю его хорошим стартом, который всегда дает базу для большинства вопросов, которые я бы хотел задать, особенно если мне нужно очень быстро составить представление о человеке.
Лучше инжекшна через конструктор только вообще без инжекшена. Мой любимый подход — это когда бины полностью отвязаны от контейнера и полностью самодостаточны. Вся контейнерная логика находится в java-конфигурации, которая инстанцирует бины явно с нужными параметрами конструктора, вызовами нужных сеттеров, при помощи билдеров или фабрик, не важно как по большому счету. Все инжекшены на уровне конфигурации. Тем самым мы выносим логику инициализации контекста выполнения и создаем косвенность на уровне конфигурации. Зато нам не важно какие объекты у нас выступают в роли бинов. Как заанотированы их поля или конструкторы. Мы можем тестировать этот бин без какой-либо привязке к инжекшенам вообще и делать бины более нативными для языка. Лично для меня это намного более чисто, гибко и представляется как конструктор, где бины это просто классы, которые мы собираем при помощи конфигурации и можем при желании сделать конфигурации разными, гибкими и настраиваемыми. Т.е. есть у меня есть класс TcpServer из реактора, я могу просто получить в один бин конфиг, передать его в другой метод декларации бина и там на основе этих параметров инстанцировать уже сам сервер. Хотя сам сервер если разобраться ничего не знает о контейнерах. То же и с другими компонентами — хорошо, если они никак не завязаны на инжекшн и могут работать независимо — в этом смысле правильное поведение бина, если он всё зависимости принимает в конструктор и просто не создается без них. Мы так проектируем обычные классы, почему те, что мы используем в контейнере должны чем-то отличаться? К слову в самом спринге всё примерно так и сделано (бут вообще весь состоит из таких конфигураций). Нигде вы не увидите аннотаций @Service или @Inject, потому, что всё драйвится внешними конфигами, в свою очередь потому, что это дает возможность гибкости и настриваемости. Не вижу причин, почему мой код не может быть таким.
Да, опция достаточно смешная. На столько, что на моей памяти никто её не предложил. Обычно люди всё же пытаются решать ту задачу, которую им предложили решить, что часто бывает не менее полезно, чем инициативность.
обычно нет, но как я написал выше, тут дело не в самой циклической зависимости, а в том как человек будет думать об этой задаче. Знает ли он о том, что спринг умеет проксировать бины? Предложит ли он использовать прокси для решения такой задачи? Может быть какая-то смешная третья опция… для собеседования всё хорошо.
В реальности обычно этого никто не знает, потому что, во-первых, плохой тон, во-вторых, нужно очень редко. Поэтому когда человек, говорит, что не знает, тогда я спрашиваю: а как вы думаете такое вообще возможно? А если бы вы сами это собирались реализовать? И тд. А некоторые сами пытаются предположить как оно там или предполагают как это можно было бы реализовать. Кто-то говорит, что это бедпрактис. Что бы человек ни сказал, всё дает представление о нем. А ответ: не знаю и даже представить не могу — больше других.
Задавал этот вопрос про циклические зависимости в конструкторе на собеседованиях, чтобы понять уровень кандидата в спринге и вообще желании разбираться в деталях. Обычно люди не очень хорошо понимают как там всё устроено. К слову, спринг это умеет, если например сделать один из бинов лейзи
класс в котором Котлин создаёт эту функцию называется по имени файла. Например, если файл `main.kt` то класс будет `MainKt` в том пакете, который у вас в этом файле объявлен.
// зачем мейн класть в объект, а потом делать его статическим
// через костыль обратной совместимости
object AtlasGenerator {
@JvmStatic fun main(args: Array<String>) {
// ...
}
}
// если вот так вот отлично работает:
fun main(args: Array<String>) {
// ...
}
// и как раз объявляет статический методв в терминах джавы?
Имея некоторе желание и умение, можно на чем угодно написать приложение, которое будет в 10 раз медленнее, чем другое приложение делающее тоже самое. Только это не проблема спринга или томката, разруха как известно она в головах.
Пардон, а вы в свете современных веяней хотите в контексте духа святого запрос обрабатывать? Всё равно будет некоторый пул обработчиков, который будет делать собственно полезную работу. Конечно, бывает некоторая специфика, когда нам из io-треда надо отправить сразу байтики в другой асинхронный io и тогда вся эта архитектрура не очень походит, но для этих редких случаев никто и не навязывает использование томката. Можно использовать например netty-reactor или что-нибудь другое более подходящее для вашего решения. Для большинства же сервисов, когда нам нужно обработать рест запрос, пообщаться с базой и другими сервисами и ответить пользователю, вполне подойдет сервлет-апи, тем более, что начиная с 3 версии у сервлетов есть асинхронный api (и спринг это отлично поддерживает) который позволяет не занимать поток из пула, а утилизировать это время по-другому.
Это не java ee и не так уж много он реализаций стандартов за собой тащит. Как я написал выше, есть возможность подключить только core, который реализует сервер+сервлеты. Сервлеты в свою очередь это тоже не бесполезная вещь, хоть и может быть излишней для мест, где особенно важна производительность, но в общем случае они дают достаточно тонкую абстракцию, где поток байт приходящих по хттп превращается в объект запроса и диспатчится в какой-то обработчик. Это всё равно обычно микросервису нужно. Так что ваши заявления похожи на откровенные домыслы и вообще джава тормозит.
Бут умеет работать с любым сервером, из коробки есть реализации для пары самых популярных. Эмбеддед-томкат ничего лишнего не тащит уже очень давно и разбит на модули. Так что спринг-бут это как раз идеальный инструмент для микросервисов, которые на нем можно поднять в несколько строк, если еще и со спринг клауд, то и большинство проблем описанных в статье решает, так что не надо сбивать людей.
У терминов operator, operation, operand есть вполне буквальные русские аналоги: оператор, операция и операнд. Все эти слова есть в русском и используются для обозначения идентичных сущностей, что и в английском языке. Оператор — это тот кто производит операцию, операнд — это тот над кем её проводят, ну а операция — это собственно производимое действие. Спутать их при всем желании невозможно. Со statement всё немного сложнее, потому что в русском языке нет прямого перевода этого слова в том значении, в котором его используют в семантике языка программирования. Его можно перевести как «инструкция», что, к слову, не сильно увеличивает понимание этого термина. То, что раньше все это переводилось как оператор — это скорее всего просто не желание переводчика задуматься о сути терминов.
Да, есть di контейнеры, которые гарантируют консистентность на уровне компиляции, но это накладывает другие серьезные ограничения на них, которых у спринга нет. Выбирайте, что вам важнее.
Звучит как «если вы взяли какую-то другую библиотеку, то она не падает в рантайме если ей забыли пропертю подсунуть в файл».
Нет, обычно проблемы появляются по одной, а если ваш код вообще не работает, то вряд ли стоит в этом винить спринг.
То есть вы искреннее считаете, что тот факт, что вы не можете сделать большое приложение на спринге, означает, что никто не может? Я обсолютно согласен с тезисом, что если сложность фреймворка вас пугает, не надо его использовать. Возьмите что-то попроще, возможно ничего более сложного и не потребуется. Остальное можно и напедалить. Но не нужно винить в этом спринг — он лишь инструмент, которым вы или умеете пользоваться и получаете то, что нужно или нет. Лично для меня важно, что я могу воспользоваться готовыми решениями и их интеграцией из коробки, а не писать их заново. Конечно никакое решение не идеально в том числе и спринг, просто не нужно строить на этот счет иллюзий и выбирать инструмент по себе и своей задаче.
Еще хочу заметить, что спринг в первую очередь это система интеграции сторонних библиотек и решений, а не какие-то конкретные решения (хотя конечно и они есть), более того обычно ты можешь выбирать какие реализации ты будешь использовать и из коробки идет несколько. Я это к тому, что спринг не просто не исключает использования набора простых решений, но напротив именно к тому тебя и подталкивает и предоставляет удобные способы их интегрировать в приложение, многие прямо из коробки.
Это вы как профессионал так хорошо обобщили?
Выше писал о том, что правильный ответ здесь не важен, к тому же его обычно никто не знает. И лично мне на денежные претензии кандидата глубоко плевать, потому что моя сфера — это исключительно его техническая компетенция.
У меня много способов потратить время, но если я провожу интервью, то я трачу время именно на это. Мне нужно максимально быстро получить представление о человеке как о специалисте и коллеге, а этот вопрос не только позволяет в редких случаях выявить человека, который разбирается в нужном мне стеке, но и дает огромное количество материала для обсуждения и понимания уровня кандидата. Лично меня вообще не интересует может ли кандидат засунуть квадратный люк в круглый колодец или знает ли он наизусть все методы
SessionImplementor, на мой взгляд в первую очередь важны личные качества кандидата и как он себе представляет разработку, насколько он четко мыслит в этом направлении. Всё это можно выяснить начиная с этого вопроса.Вопрос этот очень богат коннотациями, например, он позволяет посмотреть насколько человек представляет как работает язык: кто-то вообще не понимает в чем проблема передать в конструкторы двум классам друг друга. Показывает насколько человек глубоко знает спринг, потому что совершенно не обязательно знать правильный ответ на этот вопрос, чтобы предположить как спринг себя поведет в той или иной ситуации. Если же человек сразу отвечает, то скорее всего он человек прошаренный и можно много времени сэкономить. Опять же, я не требую правильного ответа на этот вопрос, а лишь считаю его хорошим стартом, который всегда дает базу для большинства вопросов, которые я бы хотел задать, особенно если мне нужно очень быстро составить представление о человеке.
TcpServerиз реактора, я могу просто получить в один бин конфиг, передать его в другой метод декларации бина и там на основе этих параметров инстанцировать уже сам сервер. Хотя сам сервер если разобраться ничего не знает о контейнерах. То же и с другими компонентами — хорошо, если они никак не завязаны на инжекшн и могут работать независимо — в этом смысле правильное поведение бина, если он всё зависимости принимает в конструктор и просто не создается без них. Мы так проектируем обычные классы, почему те, что мы используем в контейнере должны чем-то отличаться? К слову в самом спринге всё примерно так и сделано (бут вообще весь состоит из таких конфигураций). Нигде вы не увидите аннотаций@Serviceили@Inject, потому, что всё драйвится внешними конфигами, в свою очередь потому, что это дает возможность гибкости и настриваемости. Не вижу причин, почему мой код не может быть таким.У терминов operator, operation, operand есть вполне буквальные русские аналоги: оператор, операция и операнд. Все эти слова есть в русском и используются для обозначения идентичных сущностей, что и в английском языке. Оператор — это тот кто производит операцию, операнд — это тот над кем её проводят, ну а операция — это собственно производимое действие. Спутать их при всем желании невозможно. Со statement всё немного сложнее, потому что в русском языке нет прямого перевода этого слова в том значении, в котором его используют в семантике языка программирования. Его можно перевести как «инструкция», что, к слову, не сильно увеличивает понимание этого термина. То, что раньше все это переводилось как оператор — это скорее всего просто не желание переводчика задуматься о сути терминов.