>где в онлайне можно посмотреть сколько света вы намотали, потом нажать кнопку «оплатить» и тут же оплатить в онлайне через интернет-банк не выходя из дому.
электричество везде периодами оплачивается. какой смысл смотреть сколько там прямо сейчас «намотали»? а сколько затрачено за прошедший месяц и переход на оплату много где есть. Более того, есть страны где и нажимать ничего не надо, поставщик энергии сам снимет бабло с вашего счета по доверительному поручению.
Согласен, что майндстормсу не хватает простых микромоторов, редуктор вообще не проблема собрать на самом лего, что и с образовательной точки зрения предпочтительнее. А еще огромные претензии к стандартному майндстормс софту.
есть две основные серии лего — классическая с вариантами, и текникс, mindstorms заточен под вторую, т.е. если вы будете собирать что-то сложное, и вам не хватит деталей стандартного набора, то вам нужны будут наборы текникс, правда, я особой проблемы не вижу
Просто автор выбрал совсем неподходящие языки для сравнения, а ведь есть прямой аналог из второй половины 90х — это Visual Basic, в то время язык нежно любимый за низкий порог входа и хорошую интеграцию со сторонними библиотеками, получивший особенно широкое распространение в эпоху американского бума IT.
Не обязательно у лего покупать, есть чудесный магазин bricklink где частные лица продают друг-другу лего россыпью, иногда новые детали, иногда со следами зубов :), бывает, что сильно выгоднее, чем набор брать. Или, к примеру, если надо один мотор для майндстормса докупить.
С отдельными шестеренками это сработает, с обычными блоками — нет. Когда у вас друг на друге стоят, например, шесть блоков, суммарное отклонение будет довольно значительным, что-то вообще не удастся соединить, где-то потребуется приложение изрядной силы и т.д.
Открою секрет — даже китайским «лего» деталям, изготовленным литьём, не хватает точности. Они с трудом подходят друг к другу. Куда уж там домашним 3Д принтерам. Можно изготовить отдельные сложные детали и потом дотачивать их напильником/шкуркой/микрофрезой, но не больше.
Они к constructor injection призывать начали относительно поздно. И это реально стало «поздно», потому что в целом это редко выполняется даже в рамках проектов под зонтиком spring.
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?
Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
«Это» — использование аннотаций для решения любых фантазий, несмотря на то, что они жестко привязывают код к конкретной реализации контейнера, несмотря на то, что содержание аннотаций невозможно валидировать на этапе компиляции и тяжело рефакторить и т.д. и т.п.
Разумеется, повальное увлечение аннотациями началось раньше спринга, но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.
Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое) Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
да, собственная реализация — отличный подход для понимания внутренностей чего-либо.
к сожалению, повторяя спринг без критического взгляда на его концептуальное устройства вы повторяете его со всеми присущими ему граблями, даже не задумываясь — типа, раз в спринге так сделано, значит так и надо делать :)
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
И то и другие на больших объемах данных (сотни ГБ в день) требует настройки человеком, понимающим, что там внутри, но с ELK это происходит уже на меньших объемах, в силу особенностей elasticsearch, иначе все начинает тормозить. С другой стороны, обычно легче найти человека с опытом elasticsearch, чтобы он сделал все как надо.
Спланк из коробки очень хорошо умеет извлекать из логов ключи-значения, интерфейс, поисковая строка и возможности в целом более интеллектуальны, отточены за многие годы существования системы. Стоит ли оно запрашиваемых денег — совсем отдельный вопрос.
На мой взгляд, Кибана до сих пор страшно сырая. Elasticsearch отличный продукт, но требует понимания.
электричество везде периодами оплачивается. какой смысл смотреть сколько там прямо сейчас «намотали»? а сколько затрачено за прошедший месяц и переход на оплату много где есть. Более того, есть страны где и нажимать ничего не надо, поставщик энергии сам снимет бабло с вашего счета по доверительному поручению.
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли 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