Я думаю, смысл статьи не в том, чтобу указать на что-то важное/критичное, а показать бессмысленность термина «тяжеловесный» в применении к крайним версиям Java EE. Я согласен с автором в том, что, начиная с версии 6, Java EE более не является тяжеловесным.
Нативное приложение всегда лучше чем кроссплатформенное
Всё-таки не следует противопоставлять native и cross-platform приложения. Потому что последнее может быть скомпилировано в native код для нескольких требуемых платформ.
Пример: C/C++ приложения (как консольные, так и с GUI), компилируемые из одних и тех же исходников в бинарники для Linux, Windows и Mac OS X.
Впрочем, если заказчик и исполнитель — одно и тоже лицо (пусть и юридическое), то это меняет дело: даже полное изменение требований в уже начатом процессе разработки может быть гибким и простым делом.
Насчет частой путаницы — это верно. Причем вот этот самый перевод привносит дополнительную порцию путаницы.
Типичнейший пример: команда принимает требования к продукту за свою цель
Реализация системы по требованиям к продукту, утвержденным заказчиком, и есть цель для исполнителя (разработчика). Если исполнителю кажется неуместной часть требований, то он может попытаться инициировать их пересмотр.
В оригинале более уместная формулировка:
A common example is when teams treat a design specification as a goal.
Обратите внимение, что речь идет не о functional (system requirements) specification, а о design specification.
Требования, архитектура, дизайн приложения — это ограничение.
В общем неверно, т.к. обычно только малая часть требований и деталей дизайна является ограничениями. В оригинале более правильно:
A software design is a constraint.
Хотя и это не всегда так: обычно есть какие-то design constraints, но дизайн в целом не является ограничением. Он даже может меняться в процессе реализации без участия заказчика при неизменных исходных требованиях и ограничениях.
В целом, в зависимости от контекста, совет автора оригинальной статьи может быть как полезным, так и вредным советом: вы можете не только завалить многомиллинный проект, но и понести за это полную ответственность («Вы ограничения на дизайн в утвержденной спецификации видели? А что наваяли?!!! :-\»).
старый спор с коллегой о том, как программисту следует относиться к требованиям к продукту. Коллега утверждал, что требование нужно реализовывать дословно, даже если оно неполное или не оптимальное. Я же пытался доказать ошибочность такого формального подхода.
Ваш коллега был прав. Все эти спецификации — не что иное как формализация требований заказчика, потому и относиться к готовой спецификации следует формально. Свой творческий подход вы можете использовать на этапе анализа задач и сбора требований заказчика, но после утверждения просто выполнять его. А для внесения изменений есть свой формальный процесс.
Я бы добавил «Этап 0» (он же «Этап 7»): как можно чаще использовать RAII (т.е. автоматическое выделение памяти) вместо динамического выделения.
Хотя полностью избавиться от динамического выделения удается редко, однако к этому следует стремиться, т.к. RAII по сути — это compile-time «garbage collector», простой, надежный, быстрый и масштабируемый.
Да. Инспекция, использование и модификация произвольных классов (даже неизвестных на момент компилирования) это reflection. Как и создание экземпляра класса таким способом (например, динамически нашли конструктор с нужной сигнатурой и вызвали его, подставив параметры).
Создание экземпляра класса через оператор new внутри factory (как и без factory) — нет.
Нет, создание экземпляра класса при помощи factory не относится к reflection даже в Java. Это просто factory design pattern, который может использовать reflection, но в общем никак с ней не связан.
Создание экземпляра класса вызовом factory, найденным по некоторому ключу в map, это не reflection. И для этого не нужны ни run-time, ни compile-time reflection.
Если нужна сериализация, то ProtoBuffers (или Thrift, а также несколько иных) могут это, причем в разных форматах. Плюс к этому — решение interoperability «из коробки» и дополнительный или встроенный (Thrift) клиент/сервер (если они вам нужны, конечно).
Да, дополнительные исходники действительно автоматически создатся из описания интерфейса, сделанного на IDL. Однако для многих задач наличие IDL скорее плюс, чем минус. Например, для тех же сетевых интерфейсов и interoperability. Сам процесс генерирования исходников легко встраивается в любые build-системы, включая используемый вами cmake.
А вообще, тема «run-time reflection in C++» довольно спорная. Например, «отец-онователь» всегда был против, согласившись только на compile-time. Поэтому ваша библиотека будет, скорее всего, нишевой с ограниченным количеством пользователей.
«Всеобщее умение программировать» вовсе не обязательно означает «умение алгоритмически мыслить и кодить на языках программирования».
И вообще, программирование не самоцель. Если управление различными компьютерами (куда относятся и куча встраиваемых деайсов), включая описание новых задач («программирование»), возможно через простые интерфейсы или даже на естественных языках, зачем нам вообще «всеобщее умение программировать» в том смысле, о котором вы (вероятно) сожалеете?
Так что мы не только ничего не слили, но и развились намного дальше большинства прежних представлений об использовании ЭВМ. И окончания этого развития пока не ожидается :-)
Это, конечно, правильно, но с другой стороны хочется, чтобы и работа была не просто хорошо оплачиваемая, но и интересная. А интересная работа в программировании (да и не только там), как правило, связана с челленджами разной степени сложности. Поэтому обычно не «челлендж ради челленджа», а челлендж ради саморазвития и морального удовлетворения. А если это еще и с целями фирмы совпадает (оптимальный вариант, при определенном опыте легко достигаемый), то и для повышения личного благосостояния :-)
Хотя следует оговорить, что челленджи можно найти практически везде и с любым языком. Впрочем, избегать их можно тоже везде.
Крайние версии JavaEE 6 и 7 не являются такими сложными и монструозными, как прежние, а JEE Web Profile вообще прост и удобен (пример JEE 6 Web Profile: http://tomee.apache.org )
Относительно экспериментов в невесомости без вывода на орбиту:
такая потребность действительно существует.
Причем в зависимости от требований (включая стоимость и размеры) применяют самые различные средства: от бросковых эксперментов (в drop tower) до суборбитальных ракет (sounding rockets).
У нас тоже все в Java team вздохнули с облегчением после перехода на embedded TomEE :-)
Всё-таки не следует противопоставлять native и cross-platform приложения. Потому что последнее может быть скомпилировано в native код для нескольких требуемых платформ.
Пример: C/C++ приложения (как консольные, так и с GUI), компилируемые из одних и тех же исходников в бинарники для Linux, Windows и Mac OS X.
Реализация системы по требованиям к продукту, утвержденным заказчиком, и есть цель для исполнителя (разработчика). Если исполнителю кажется неуместной часть требований, то он может попытаться инициировать их пересмотр.
В оригинале более уместная формулировка:
Обратите внимение, что речь идет не о functional (system requirements) specification, а о design specification.
В общем неверно, т.к. обычно только малая часть требований и деталей дизайна является ограничениями. В оригинале более правильно: Хотя и это не всегда так: обычно есть какие-то design constraints, но дизайн в целом не является ограничением. Он даже может меняться в процессе реализации без участия заказчика при неизменных исходных требованиях и ограничениях.
В целом, в зависимости от контекста, совет автора оригинальной статьи может быть как полезным, так и вредным советом: вы можете не только завалить многомиллинный проект, но и понести за это полную ответственность («Вы ограничения на дизайн в утвержденной спецификации видели? А что наваяли?!!! :-\»).
Ваш коллега был прав. Все эти спецификации — не что иное как формализация требований заказчика, потому и относиться к готовой спецификации следует формально. Свой творческий подход вы можете использовать на этапе анализа задач и сбора требований заказчика, но после утверждения просто выполнять его. А для внесения изменений есть свой формальный процесс.
Хотя полностью избавиться от динамического выделения удается редко, однако к этому следует стремиться, т.к. RAII по сути — это compile-time «garbage collector», простой, надежный, быстрый и масштабируемый.
Создание экземпляра класса через оператор new внутри factory (как и без factory) — нет.
В простейшем варианте — при помощи switch/case или статического map<string,Factory>.
Зависит от того, что вам действительно нужно.
Если нужна сериализация, то ProtoBuffers (или Thrift, а также несколько иных) могут это, причем в разных форматах. Плюс к этому — решение interoperability «из коробки» и дополнительный или встроенный (Thrift) клиент/сервер (если они вам нужны, конечно).
Да, дополнительные исходники действительно автоматически создатся из описания интерфейса, сделанного на IDL. Однако для многих задач наличие IDL скорее плюс, чем минус. Например, для тех же сетевых интерфейсов и interoperability. Сам процесс генерирования исходников легко встраивается в любые build-системы, включая используемый вами cmake.
А вообще, тема «run-time reflection in C++» довольно спорная. Например, «отец-онователь» всегда был против, согласившись только на compile-time. Поэтому ваша библиотека будет, скорее всего, нишевой с ограниченным количеством пользователей.
Почему, собственно?
«Всеобщее умение программировать» вовсе не обязательно означает «умение алгоритмически мыслить и кодить на языках программирования».
И вообще, программирование не самоцель. Если управление различными компьютерами (куда относятся и куча встраиваемых деайсов), включая описание новых задач («программирование»), возможно через простые интерфейсы или даже на естественных языках, зачем нам вообще «всеобщее умение программировать» в том смысле, о котором вы (вероятно) сожалеете?
Так что мы не только ничего не слили, но и развились намного дальше большинства прежних представлений об использовании ЭВМ. И окончания этого развития пока не ожидается :-)
Хотя следует оговорить, что челленджи можно найти практически везде и с любым языком. Впрочем, избегать их можно тоже везде.
«Старая гвардия» как раз и представляет ту самую школу с «хорошим уровнем технического образования», о котором вы так уважительно говорите :-)
Однако Gradle без Groovy не работает => использование Gradle автоматически означает использование Groovy.
Спасибо Spring за здоровую конкуренцию :-)
такая потребность действительно существует.
Причем в зависимости от требований (включая стоимость и размеры) применяют самые различные средства: от бросковых эксперментов (в drop tower) до суборбитальных ракет (sounding rockets).
Примеры drop towers:
5 с невесомости: facilities.grc.nasa.gov/zerog
2.2 с невесомости: facilities.grc.nasa.gov/drop/index.html
Примеры суборбитальных ракет (до 15 имнут невесомости): европейские Texus, Maxus, Rexus
en.wikipedia.org/wiki/Rexus_and_Bexus
en.wikipedia.org/wiki/Maxus_%28rocket%29
en.wikipedia.org/wiki/TEXUS
В принципе, Blue Origin может предложит сравнимое с существующими ракетами время.
Согласно определению из школьного учебника, вес тела — это реакция опоры или подвеса (т.е. сила, с которой тело действует на опору или подвес).
Так что невесомость может быть на любой высоте: во время прыжка со стула вы находитесь в невесомости на высотах от 0.5 до 0 м :-)