С отдельными шестеренками это сработает, с обычными блоками — нет. Когда у вас друг на друге стоят, например, шесть блоков, суммарное отклонение будет довольно значительным, что-то вообще не удастся соединить, где-то потребуется приложение изрядной силы и т.д.
Открою секрет — даже китайским «лего» деталям, изготовленным литьём, не хватает точности. Они с трудом подходят друг к другу. Куда уж там домашним 3Д принтерам. Можно изготовить отдельные сложные детали и потом дотачивать их напильником/шкуркой/микрофрезой, но не больше.
Они к constructor injection призывать начали относительно поздно. И это реально стало «поздно», потому что в целом это редко выполняется даже в рамках проектов под зонтиком spring.
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?
Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
«Это» — использование аннотаций для решения любых фантазий, несмотря на то, что они жестко привязывают код к конкретной реализации контейнера, несмотря на то, что содержание аннотаций невозможно валидировать на этапе компиляции и тяжело рефакторить и т.д. и т.п.
Разумеется, повальное увлечение аннотациями началось раньше спринга, но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.
Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое) Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
да, собственная реализация — отличный подход для понимания внутренностей чего-либо.
к сожалению, повторяя спринг без критического взгляда на его концептуальное устройства вы повторяете его со всеми присущими ему граблями, даже не задумываясь — типа, раз в спринге так сделано, значит так и надо делать :)
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
И то и другие на больших объемах данных (сотни ГБ в день) требует настройки человеком, понимающим, что там внутри, но с ELK это происходит уже на меньших объемах, в силу особенностей elasticsearch, иначе все начинает тормозить. С другой стороны, обычно легче найти человека с опытом elasticsearch, чтобы он сделал все как надо.
Спланк из коробки очень хорошо умеет извлекать из логов ключи-значения, интерфейс, поисковая строка и возможности в целом более интеллектуальны, отточены за многие годы существования системы. Стоит ли оно запрашиваемых денег — совсем отдельный вопрос.
На мой взгляд, Кибана до сих пор страшно сырая. Elasticsearch отличный продукт, но требует понимания.
Многие думают, что это книга про то, как главный герой всё делает правильно (а потом они пытаются поймать героя и автора на косяках). На самом деле, это книга об ошибках главного героя, именно они несут главный педагогический эффект.
Если после 20й не нравится, то да, можно не продолжать. Это же вопрос вкусов.
помимо того, что яблоки задают моду по многим направлениям, я бы заметил, что они сделали это вовремя, а HTC поторопились, им всё равно пришлось продавать телефоны с адаптером
Позабавило упоминание Оппо 2012г, убравшего мини-джек.
Да будет известно автору, самый первый андроид-смартфон T-Mobile G1, вышедший в 2008г был без мини-джека.
Фича уже встроена в cyanogen/lineage как минимум с 12й версии. выбираем какие приложения закрыть, задаем pattern-lock, заодно защищаем и меню настроек от случайного изменения. Я тоже изрядное время потратил на поиски вменяемой программы для закрытия play market.
"// Блокируем текущий поток до тех пор пока не получим объект"
ничего, что это чуть ли не главная проблема, которую реактивный подход пытается решить? :) а вы прямо под этим примером гордо пишете «использовать реактивный подход довольно просто»
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?
Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
Разумеется, повальное увлечение аннотациями началось раньше спринга, но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.
Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое) Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
к сожалению, повторяя спринг без критического взгляда на его концептуальное устройства вы повторяете его со всеми присущими ему граблями, даже не задумываясь — типа, раз в спринге так сделано, значит так и надо делать :)
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
И то и другие на больших объемах данных (сотни ГБ в день) требует настройки человеком, понимающим, что там внутри, но с ELK это происходит уже на меньших объемах, в силу особенностей elasticsearch, иначе все начинает тормозить. С другой стороны, обычно легче найти человека с опытом elasticsearch, чтобы он сделал все как надо.
Спланк из коробки очень хорошо умеет извлекать из логов ключи-значения, интерфейс, поисковая строка и возможности в целом более интеллектуальны, отточены за многие годы существования системы. Стоит ли оно запрашиваемых денег — совсем отдельный вопрос.
На мой взгляд, Кибана до сих пор страшно сырая. Elasticsearch отличный продукт, но требует понимания.
уж поверьте, для написания свинг приложений не требуются какие-то особенные квалифицированные кадры, достаточно обычных людей с руками из плеч.
en.wikipedia.org/wiki/Triune_brain#Status_of_the_model
Если после 20й не нравится, то да, можно не продолжать. Это же вопрос вкусов.
считаю, еще очень важен вопрос «когда не стоит использовать спринг?»
Да будет известно автору, самый первый андроид-смартфон T-Mobile G1, вышедший в 2008г был без мини-джека.
ничего, что это чуть ли не главная проблема, которую реактивный подход пытается решить? :) а вы прямо под этим примером гордо пишете «использовать реактивный подход довольно просто»