Мое впечатление, что в каждом деле здесь упор делают на рациональность и практичность. Если бы имбирь, ацц, малина или хоть что-то еще помогали их бы мне порекомендовал семейный врач по телефону.
Парацетамол был объективно нужен. Технически головную боль, боли в мышцах и высокую температуру можно перетерпеть. Но поспать не получится. Засыпая начинаешь стонать во сне и будишь сам себя.
Когда поступил в отдельной маленькой палате был, с душем и туалетом. Потом перевели в большую, там душ и туалет были на 3 палаты. Большая комната, 2 кабинки туалеты с раковинами, одна большая чтобы на коляске было удобно. И две душевые кабинки. Но на 3 палаты в каждой по 3 человека.
Как бы коридорчик с выходом на маленькую террасу, но из-за короны терраса была закрыта, 3 палаты и туалет/душ. В коридоре был диванчик, но им тоже нельзя было пользоваться. Можно было только в туалет и душ выходить.
В палатах возле кроватей все оборудование на стенах висит. Всякие мониторы, кислородные маски, даже ЭКГ возле каждой кровати.
Большая доля везения. В медицинских записях первоначальное назначение Ремдисивир 5 дней, Дексаметазон 10 дней. А фактически меньше чем через сутки лечение уже прекратили.
Привожу только для информации. Не опирайтесь на мои слова при лечении! Следуйте рекомендации вашего врача!
Сразу как поступил капали физраствор (NaCl 0.9%) и дали 2 таблетки парацетамола.
Лечение: remdesivir капельницей 2 раза по 250мл, но флакон конкретно для меня был, с моим именем/фамилией на нем. Там были еще цифры: дозировка, частота, продолжительность, скорость...
И dexamethason. Как я понял это были 2 маленькие таблетки которые мне дали вечером и в 10 утра следующего дня.
Пример:
Предположим, на следующий год вы можете влиться в одну из двух команд.
Всё примерно одинаково: по 4 человека в командах, тип приложения в обоих случаях "как вы любите", размеры исходного кода, количество пользователей, выручка… всё примерно одинаково.
Но в одном случае у проекта на дашборде светится 62.4% code coverage (а на начало прошлого года — 55%), а у другого проекта этой цифры вообще нет и никто даже примерно ее не знает.
В какую команду вы пойдете?
К сожалению автор оригинальной статьи не удосужился проверить свои аргументы.
А между тем, эти аргументы слабенькие, а некоторые — ложные.
1)
Добавлять новые зависимости просто.
При использовании Idea любую зависимость добавлять легко, так что это не аргумент.
Кроме того нет смысла что-то усложнять.
2)
… после определенного момента число аргументов конструктора становится слишком большим и тут же становится очевидно, что что-то не так.
Тем не менее это не ведет к улучшению архитектуры. Коммерческие разработчики под прессом дедлайнов тупо добавляют еще один аргумент в конструктор. Благо с Идеей это легко. Когда же разработчики берутся за рефакторинг, то они выбирают классы не по числу аргументов конструкторов, а по размеру или сложности класса. Так что и это не аргумент.
3)
Таким образом становится четко понятно, что требует класс...
Кому? DI контейнер однозначно "поймет", что требует класс (а точнее бин!) при любом объявлении зависимостей.
Разработчику зависимых бинов совершенно без разницы от чего зависит ваш бин. При написании юнит-тестов разработчику доступен исходный код класса — так что, чем меньше кода — тем лучше.
4)
… а также опциональные ли это зависимости (через сеттеры) или обязательные (конструктор)
Увы это ложь.
Например:
@Autowired public void setTest(AI ai) {} // Обязательная зависимость
Если в конфигурации не будет реализации интерфейса AI, spring выбросит UnsatisfiedDependencyException, при создании такого бина.
Чтобы получить не обязательную зависимость можно использовать, например:
@Autowired(required = false) public void setTest(AI ai) {} // Необязательна зависимость
@Autowired public void setTest(Optional<AI> ai) {} // Необязательна зависимость
@Autowired public void setTest(javax.enterprise.inject.Instance<AI> ai) {} // Разрешение зависимости под вашим контролем
5)
… вы можете создать его в юнит-тесте без запуска контейнера
Использование подходящих инструментов делает юнит тесты простыми.
Например этот тест будет работать без контейнера и при любом способе внедрения зависимостей (конструктор, поля, сеттеры, с аннотациям @Autowired, Inject или вообще без них):
@RunWith(MockitoJUnitRunner.class)
public class SmartCarTest {
@InjectMocks
SmartCar smartCar;
@Mock
AI ai;
@Test
public void testDecide() {
when(ai.think()).thenReturn("42");
String decision = smartCar.decide();
assertEquals("The answer is: 42", decision);
}
}
6)
Существует способ… создать объект… приведет к NullPointerException
Это опять ложь.
В рантайме спринг либо создаст объект со всеми обязательными зависимостями, либо выбросит UnsatisfiedDependencyException. CDI или другие DI контейнеры — я уверен — ведут себя также. То же самое верно и для тестов с использованием SpringRunner.
А для тестов с использованием Mockito NullPointerException не является проблемой. Это будет просто упавший тест.
7)
… нет способа кроме рефлексии предоставить ему необходимые зависимости
Для DI контейнера это не проблема. А если класс нужно использовать вне DI контейнера, то нет смысла говорить о внедрении зависимостей. Так что это не аргумент против любого из способов.
8)
… внедрение через поля не может использоваться для присвоения зависимостей final-полям
Это верно не для всех DI контейнеров.
CDI реализации в серверах Wildfly и Payara, насколько я помню, вполне комфортно внедряют такие зависимости:
В книге Шифропанки Джулиана Ассанджа есть интересное обсуждение проблемы цензуры в сети.
Мне там понравилась цитата Вау Холланда «фильтры должен ставить конечный пользователь, причем так, чтобы они стояли в его конечном устройстве».
В javaee tutorial цель платформы Java EE объясняется так: предоставить разработчикам мощный набор API с одновременным сокращением времени разработки, снижением сложности приложения и улучшением производительности приложения.
Сравните EJB2 и EJB3 — большое количество ограничений было отменено.
т.е. приложение может переехать с одного сервера на другой
во многих частях спецификации указываются ограничения чтобы приложение оставалось «portable application». Все сервера соответствующие спецификации одинаково исполняют «portable application». Такие приложения действительно могут переезжать с одного сервера на другой.
стандарт хоть и есть, но настолько неконкретный
Можете привести пример неоднозначности в какой-нибудь части Java EE?
ведь они не только имеют собственный способ конфигурации, но и ряд «особенностей» интерпретации стандарта.
каждый сервер имеет свой собственный способ конфигурирования — это не новость, но это за рамками Java EE. И даже спринг имеет свой собственный способ конфигурирования. Специалист по TomEE/Payara/Wildfly/Weblogic сможет настроить сервер. Однако сила Java EE в том, что разработчик может создавать компоненты независимо от конфигурации и модели конкретного сервера.
но развитие стандартов по причине высокой формализации идут совершенно не современными темпами
в 2009 Java EE 6, в 2013 Java EE 7, в конце этого 2016 ожидается Java EE 8. Сейчас в Java EE 7 есть всё. Асинхронные запросы, Web Sockets, REST, HTML 5.
В Java EE 8 (в конце этого года) ожидается HTTP/2, Server-Sent Events. Темпы, на мой взгляд, превосходные!
javaee никак не может разобраться с тем как приложение тестировать
Java EE (на сколько мне известно) не имеет своей целью определить как тестировать что-либо. Так что это утверждение не корректное.
Однако тесто-пригодность java ee приложений на высоте (так же как у спринг приложений).
Автор оригинальной статьи рекомендует вместо интеграционных «системные тесты» с использованием контейнеров. Вполне пригодная концепция.
А для модульных тестов (как для java ee так и для spring) отлично подходит mockito с её аннотациями InjectMocks, Mock, Spy.
Может лучше было бы выпустить хорошие реализации для этих технологий
имхо оракл поступил даже мудрее! Вместо того чтобы выпускать самому, он сделал так, что теперь для каждого компонента имеются несколько реализаций JPA - Hibernate, EclipseLink, OpenJPA
JTA - Narayana (других не знаю, но они есть)
JAX-RS - Apache CXF, Jersey, RESTeasy
Серверы приложений Wildfly, Payara, TomEE, WebLogic, WebSphere — на любой вкус.
Я с большим уважением отношусь к Spring. Это отличный фреймворк. Однако и спецификация Java EE предлагает как минимум такой же уровень возможностей и удобства.
Какие-то части из оригинальной статьи пропущены?
Например это:
I've written about this in Strict Control of Java Code Quality. I use qulice.com in Java projects and rubocop in Ruby, but there are many similar tools for nearly every language.
В самом конце автор оригинальной статьи упоминает «автоматическое системное тестирование развернутого в контейнер приложения». Как мне показалось, он его предлагает вместо интеграционного тестирования с локальным подъемом внедренного сервера приложений.
Насчет отличия таких областей в вики есть удачная метафора:
Если бы P была гвоздём, а C была бы завязанным в кольцо куском нитки, вытягивание какой-то части нитки прочь от гвоздя приведёт либо к вытягиванию всей нитки, либо нитка окажется накрученной несколько раз на гвоздь
Мое впечатление, что в каждом деле здесь упор делают на рациональность и практичность. Если бы имбирь, ацц, малина или хоть что-то еще помогали их бы мне порекомендовал семейный врач по телефону.
Парацетамол был объективно нужен. Технически головную боль, боли в мышцах и высокую температуру можно перетерпеть. Но поспать не получится. Засыпая начинаешь стонать во сне и будишь сам себя.
Да. Чай пил обычный из пакетиков, после еды обычно.
В отеле пробыл 4 ночи, потом 2 в госпитале, и после 2 в отеле. Пока был в госпитале мои вещи оставались в комнате отеля.
Велосипед с батарейкой, погода хорошая, так что доехать на велосипеде было не сложно.
Не совсем. Я ни куда не ходил. Сначала потому что был в карантине после поездки, а потом потому что появились симптомы.
В целом да. См. сообщение начинается со слов "Привожу только для информации"
Когда поступил в отдельной маленькой палате был, с душем и туалетом. Потом перевели в большую, там душ и туалет были на 3 палаты. Большая комната, 2 кабинки туалеты с раковинами, одна большая чтобы на коляске было удобно. И две душевые кабинки. Но на 3 палаты в каждой по 3 человека.
Как бы коридорчик с выходом на маленькую террасу, но из-за короны терраса была закрыта, 3 палаты и туалет/душ. В коридоре был диванчик, но им тоже нельзя было пользоваться. Можно было только в туалет и душ выходить.
В палатах возле кроватей все оборудование на стенах висит. Всякие мониторы, кислородные маски, даже ЭКГ возле каждой кровати.
Большая доля везения. В медицинских записях первоначальное назначение Ремдисивир 5 дней, Дексаметазон 10 дней. А фактически меньше чем через сутки лечение уже прекратили.
Привожу только для информации. Не опирайтесь на мои слова при лечении! Следуйте рекомендации вашего врача!
Сразу как поступил капали физраствор (NaCl 0.9%) и дали 2 таблетки парацетамола.
Лечение: remdesivir капельницей 2 раза по 250мл, но флакон конкретно для меня был, с моим именем/фамилией на нем. Там были еще цифры: дозировка, частота, продолжительность, скорость...
И dexamethason. Как я понял это были 2 маленькие таблетки которые мне дали вечером и в 10 утра следующего дня.
Вместо настроек, которые я привел в статье я бы очень рекомендовал Git Large File Storage (LFS) https://git-lfs.github.com/
Пример:
Предположим, на следующий год вы можете влиться в одну из двух команд.
Всё примерно одинаково: по 4 человека в командах, тип приложения в обоих случаях "как вы любите", размеры исходного кода, количество пользователей, выручка… всё примерно одинаково.
Но в одном случае у проекта на дашборде светится 62.4% code coverage (а на начало прошлого года — 55%), а у другого проекта этой цифры вообще нет и никто даже примерно ее не знает.
В какую команду вы пойдете?
СС — это технологическая метрика. Она не много говорит о качестве программного продукта. Зато кое-что говорит о качестве процесса его разработки!
К сожалению автор оригинальной статьи не удосужился проверить свои аргументы.
А между тем, эти аргументы слабенькие, а некоторые — ложные.
1)
При использовании Idea любую зависимость добавлять легко, так что это не аргумент.
Кроме того нет смысла что-то усложнять.
2)
Тем не менее это не ведет к улучшению архитектуры. Коммерческие разработчики под прессом дедлайнов тупо добавляют еще один аргумент в конструктор. Благо с Идеей это легко. Когда же разработчики берутся за рефакторинг, то они выбирают классы не по числу аргументов конструкторов, а по размеру или сложности класса. Так что и это не аргумент.
3)
Кому? DI контейнер однозначно "поймет", что требует класс (а точнее бин!) при любом объявлении зависимостей.
Разработчику зависимых бинов совершенно без разницы от чего зависит ваш бин. При написании юнит-тестов разработчику доступен исходный код класса — так что, чем меньше кода — тем лучше.
4)
Увы это ложь.
Например:
Если в конфигурации не будет реализации интерфейса AI, spring выбросит UnsatisfiedDependencyException, при создании такого бина.
Чтобы получить не обязательную зависимость можно использовать, например:
5)
Использование подходящих инструментов делает юнит тесты простыми.
Например этот тест будет работать без контейнера и при любом способе внедрения зависимостей (конструктор, поля, сеттеры, с аннотациям @Autowired, Inject или вообще без них):
6)
Это опять ложь.
В рантайме спринг либо создаст объект со всеми обязательными зависимостями, либо выбросит UnsatisfiedDependencyException. CDI или другие DI контейнеры — я уверен — ведут себя также. То же самое верно и для тестов с использованием SpringRunner.
А для тестов с использованием Mockito NullPointerException не является проблемой. Это будет просто упавший тест.
7)
Для DI контейнера это не проблема. А если класс нужно использовать вне DI контейнера, то нет смысла говорить о внедрении зависимостей. Так что это не аргумент против любого из способов.
8)
Это верно не для всех DI контейнеров.
CDI реализации в серверах Wildfly и Payara, насколько я помню, вполне комфортно внедряют такие зависимости:
В книге Шифропанки Джулиана Ассанджа есть интересное обсуждение проблемы цензуры в сети.
Мне там понравилась цитата Вау Холланда «фильтры должен ставить конечный пользователь, причем так, чтобы они стояли в его конечном устройстве».
В javaee tutorial цель платформы Java EE объясняется так: предоставить разработчикам мощный набор API с одновременным сокращением времени разработки, снижением сложности приложения и улучшением производительности приложения.
Сравните EJB2 и EJB3 — большое количество ограничений было отменено.
во многих частях спецификации указываются ограничения чтобы приложение оставалось «portable application». Все сервера соответствующие спецификации одинаково исполняют «portable application». Такие приложения действительно могут переезжать с одного сервера на другой.
Можете привести пример неоднозначности в какой-нибудь части Java EE?
каждый сервер имеет свой собственный способ конфигурирования — это не новость, но это за рамками Java EE. И даже спринг имеет свой собственный способ конфигурирования. Специалист по TomEE/Payara/Wildfly/Weblogic сможет настроить сервер. Однако сила Java EE в том, что разработчик может создавать компоненты независимо от конфигурации и модели конкретного сервера.
в 2009 Java EE 6, в 2013 Java EE 7, в конце этого 2016 ожидается Java EE 8. Сейчас в Java EE 7 есть всё. Асинхронные запросы, Web Sockets, REST, HTML 5.
В Java EE 8 (в конце этого года) ожидается HTTP/2, Server-Sent Events. Темпы, на мой взгляд, превосходные!
Java EE (на сколько мне известно) не имеет своей целью определить как тестировать что-либо. Так что это утверждение не корректное.
Однако тесто-пригодность java ee приложений на высоте (так же как у спринг приложений).
Автор оригинальной статьи рекомендует вместо интеграционных «системные тесты» с использованием контейнеров. Вполне пригодная концепция.
А для модульных тестов (как для java ee так и для spring) отлично подходит mockito с её аннотациями InjectMocks, Mock, Spy.
имхо оракл поступил даже мудрее! Вместо того чтобы выпускать самому, он сделал так, что теперь для каждого компонента имеются несколько реализаций
JPA - Hibernate, EclipseLink, OpenJPA
JTA - Narayana (других не знаю, но они есть)
JAX-RS - Apache CXF, Jersey, RESTeasy
Серверы приложений Wildfly, Payara, TomEE, WebLogic, WebSphere — на любой вкус.
Я с большим уважением отношусь к Spring. Это отличный фреймворк. Однако и спецификация Java EE предлагает как минимум такой же уровень возможностей и удобства.
?!
Например это:
Или это оригинал поменялся?
Насчет отличия таких областей в вики есть удачная метафора:
Бывает «even-odd winding rule» и «non-zero winding rule».
В первом случае красная точка считается за пределами полигона (как у автора), во-втором — внутри.