Идея интересная, но содержит неприятную проблему: в одном файле может быть несколько классов и ни один из них не будет называться по имени файла (файл — это модуль, внутри множество классов).
На небольших проектах, где количество классов будет стремиться к десяткам Ваш подход через конфигурацию будет вполне удобным, для большого проекта написать конфигурацию будет ужасной болью.
А рефакторить и всячески поддерживать данный подход будет еще больнее.
Пока в JS | ES не будет полноценной поддержки метаданных (декораторов, аннотаций), реализовать полноценный DI будет практически невозможно. А при отсутствии типов поддерживать и отлаживать такой DI контейнер будет сложно.
Наличие стандартной регистрации компонентов для DI сводит различие между всеми реализациями DI контейнеров к минимуму. Отличие будет в управлении памятью, аллокацией и построением графа зависимостей.
Одна из удачных реализаций: помечать мета-данными конструкторы / сеттеры / поля, А конфигурация всех зависимостей остается на плечах имплементации.
В результате все контейнеры смогут выполнять свою функци и не будут ограничены в том, как организовывать свою конфигурацию, а значит и возможностей для развития у них будет больше.
С таким же успехом можно продемонстрировать связь скажем с JDBC.
Речь не про зависимости от Спецификации (от JSR330), а именно про зависимость от конкретной имплементации этой спеки.
Если бы JAX-RS для своей работы требовал конкретную имплементацию JDBC, по-моему это был бы полный провал.
покажите тогда связь между faces и jms
Не уверен, что такая связь есть. Хотя я бы не стал исключать вероятность, что она есть.
А если посмотреть выше на мой коммент про связность — я не утверждал, что есть связь всего со всем. Я говорил, что сильная связность присутствует в принципе.
Непосредственно через имплементацию этих спецификаций и контейнер приложений.
Пример жесткой связи между JAX-RS и JTA я не приведу, а вот между JAX-RS и DI могу.
Jersey, он же RI для JAX-RS, за собою тянет зависимость от hk2 (имплементация DI из GlassFish).
Редко какая имплементация пишется независимо от остальных. Guice — отличный пример хорошей имплементации.
Но даже он страдает своими дополнительными удобняшками такими, как:
@Transactional
Спецификация JAX-RS не зависит даже от Servlet API, однако все известные мне имплементации — зависят.
На то, чтобы JavaSE стала модульной потратили ~8 лет! 8 лет работы высококлассных инженеров, которые работали над этим фуллтайм!!!
с JavaEE дела обстоят хуже — это набор функционала, который сильно связан между собою. Адекватно разбить его на модули займет пускай еще 5 лет. Это только референсная имплементация будет.
На дворе будет уже 2022 год. К этому времени уже Java SE 11 выйдет. В javascript появится типизация. Flash уже почти умрет. И понятие Энтерпрайз системы окончательно закрепится за теми временам, когда кроме Waterfall ничего не знали. А все, кто когда-то писал на JavaEE уже будут на пенсии.
Лучше оставить JEE в прошлом и начать разрабатывать новые системы более надежные, более поворотливые и более правильные, которым будет достаточно -Xmx=2G, чтобы поднять всю систему и чтобы она отлично при этом работала.
В свете Java 9 прикрыть JavaEE — это правильный шаг. JavaEE это легаси платформа, которая не ориентирована на модульность в терминах Java9. Если этого не сделать, компания будет терпеть убытки от поддержки технологии, которая просто не ложится в концепцию развития JavaSE.
Если продолжить поддерживать JavaEE, то под нее будет развиваться новые библиотеки и легаси код будет рождаться со старта новых проектов.
Тот же Servlet API — это крайней не приятная технология, которая морально устарела, но продолжает развиваться.
JAX-RS — новая и удобная технология, которая базируется на том же Servlet API (нельзя просто взять и уйти от легаси).
Смею не согласиться. Такой функционал крайне редко нужен (далеко не в каждом языке есть ordered dict). Но если он потребуется, то дополнительные 5-10 строк кода для обертки над таким массивом будет с головою достаточно.
Да, я понял, но не сразу.
И если на такие грабли можно наступить на столь элементарном примере, то на более сложном это может вылиться в множество потраченных минут / часов на поиск проблемы.
Вложите более-менее сложный YAML документ, как многострочное поле в AXON документе, который в свою очередь представлен в виде YAML, это вполне валидный кейс:
— вы записываете в файл данные, пришедшие извне, в формате AXON в представлении YAML, для удобства чтения.
Шутки про вложение XML в JSON (или даже JSON в JSON) смешные, пока не столкнешься с ними в реальном проекте.
Но теперь нужно писать encoder / decoder для этого формата во всех частях системы на всех языках, которые в нашей системе будут и нам очень повезет, если у нас будет язык со слабой типизацией.
Но это уже трейдоф: решили проблему объема данных, заплатили написанием кастомного парсера.
имена атрибутов/ключей, которые являются идентификаторами приходится заключать в кавычки;
легко забыть запятую в случае вставки новой пары ключ: значение.
AXON устраняет эти неудобства следующим образом:
можно не заключать в кавычки имена, которые являются идентификаторами;
совершенно опускаются разделительные запятые, используются только пробельные символы для разделения элементов.
JSON имеет куда более неприятные особенности, чем приведенные в статье.
Как вариант, в JSON необходимо каждый раз указывать все имена полей в массиве однотипных объектов. Из-за этого объем json документа существенно увеличивается.
Убрать кавычки, если ключ имеет вид идентификатора — это существенное усложнение парсера, которое позволит сэкономить 20 символов для строки длинной в 300 символов.
К тому же из документации не понятно, можно ли кавычку " или какой-то спец.символ использовать как Ключ, как вариант для конфигурации автозамены.
NodeJS однопоточна и асинхронна. Любая операция ввода-вывода не блокирует работу. Это значит, что ты можешь читать файлы, отправлять электронные письма, запрашивать базу данных и совершать другие действия… одновременно.
Вот любят возводить преимущества асинхронности в абсолют и совсем не обращать внимание на нюансы!
Асинхронность дает преимущество только для IO-bound операций. И при преобладающем количестве IO асинхронность будет рулить!
При CPU-bound операциях (сложная логика обработки данных из базы) при однопоточной модели event-loop лишь увеличивают задержку ответа.
пример: Два запроса с количеством CPU-bound операций N и K соответственно. Как ни крути, но выполнить меньше не получится. Время на выдачу первого ответа: time( N + K' ), второго: time( N' + K ), где N' и K' — это операции, которые будут выполнены благодаря переключению контекстов (асинхронно).
Если нагрузить NodeJS множеством длительных CPU-bound операций он будет обрабатывать запросы дольше, чем тот же PHP, который использует «железные» потоки.
Сравнивать PHP и NodeJS — это как сравнивать «теплое с мягким».
PHP — «живет, чтобы умирать», и в отличии от NodeJS из коробки не имеет ни пула воркеров, ни JIT, ни кешей.
У каждого из них свой путь чем-то лучше, чем-то хуже!
В прошлых статьях (проверка C#, кажется) писали, что Java проверять не интересно, т.к. это не проприетарная платформа.
И вот статья о проверке Java, интересно что повлияло на изменение курса?
Проблема не нова и всем известна. Правда мало кто задумывается о том, что является первоисточником проблемы.
Боль и убытки приносят те джуны, которые начитались бложиков по развитию от 24-летних Синьеров, которые вечно трубят, что компания и девочки-hr'очки должны целовать песок по которому они (программисты) ходили, и проповедуют переходы между компаниями каждые полгода, чтобы повысить ЗП на 20-100%.
Но если не рассматривать таких джунов, то проблема до боли простая: Джун не знает/не понимает зачем ему нужен менторинг, зачем ему пилить этот бесполезный учебный проект, который он даже в резюме не добавит, и, более того, ему даже не пытаются объяснить этого.
Нужно заинтересовать джунов, а не просто сказать «компания тратит кучу денег на взращивание», после чего каждый остается при своем мнении: «Компания меня использует и не дает ничего взамен», «Это глупый джун, который не хочет работать, а компания из-за него страдает».
А ведь если разжевать скилы и поставить цели, дать нужный курс развития и объяснить Зачем нужна какая-то фича, пусть даже в тестовом проекте, то «Младшенькому» будет интереснее и это будет для него вызов, после которого он захочет еще и еще, а не «непроходимая стена» из-за которой он будет проклинать текущую компанию и искать новую.
в качестве примера:
Бекэнд джун (java, .net, ruby, php etc.), которому дают задачу запилить фронтенд часть (html + js), джун не понимает и не хочет делать фронтенд, он же бекэндщик. Но если ему объяснить, что качественную систему можно построить только если знаешь как работают все ее компоненты и как они коммуницируют, дополнив это тем, что это повысит его ценность и востребованность на рынке труда, а самое главное — рассказать, что эта задача ему поставлена, чтобы он получил опыт интеграции двух подсистем не был упертым девом: «вот мне это сложно сделать, делай это у себя», а задумывался о сложности реализации на какой-то из сторон.
Там в тексте этого пункта было написано про наличие свободного времени.
Да и в целом когда кто-то говорит, что это не его дело — это дико раздражает, т.к. чаще всего это значит, что коллега просто не хочет работать (лучше ютубчик посмотреть).
На небольших проектах, где количество классов будет стремиться к десяткам Ваш подход через конфигурацию будет вполне удобным, для большого проекта написать конфигурацию будет ужасной болью.
А рефакторить и всячески поддерживать данный подход будет еще больнее.
Пока в JS | ES не будет полноценной поддержки метаданных (декораторов, аннотаций), реализовать полноценный DI будет практически невозможно. А при отсутствии типов поддерживать и отлаживать такой DI контейнер будет сложно.
Одна из удачных реализаций: помечать мета-данными конструкторы / сеттеры / поля, А конфигурация всех зависимостей остается на плечах имплементации.
В результате все контейнеры смогут выполнять свою функци и не будут ограничены в том, как организовывать свою конфигурацию, а значит и возможностей для развития у них будет больше.
Речь не про зависимости от Спецификации (от JSR330), а именно про зависимость от конкретной имплементации этой спеки.
Если бы JAX-RS для своей работы требовал конкретную имплементацию JDBC, по-моему это был бы полный провал.
Не уверен, что такая связь есть. Хотя я бы не стал исключать вероятность, что она есть.
А если посмотреть выше на мой коммент про связность — я не утверждал, что есть связь всего со всем. Я говорил, что сильная связность присутствует в принципе.
Пример жесткой связи между JAX-RS и JTA я не приведу, а вот между JAX-RS и DI могу.
Jersey, он же RI для JAX-RS, за собою тянет зависимость от hk2 (имплементация DI из GlassFish).
Редко какая имплементация пишется независимо от остальных. Guice — отличный пример хорошей имплементации.
Но даже он страдает своими дополнительными удобняшками такими, как:
Спецификация JAX-RS не зависит даже от Servlet API, однако все известные мне имплементации — зависят.
с JavaEE дела обстоят хуже — это набор функционала, который сильно связан между собою. Адекватно разбить его на модули займет пускай еще 5 лет. Это только референсная имплементация будет.
На дворе будет уже 2022 год. К этому времени уже Java SE 11 выйдет. В javascript появится типизация. Flash уже почти умрет. И понятие Энтерпрайз системы окончательно закрепится за теми временам, когда кроме Waterfall ничего не знали. А все, кто когда-то писал на JavaEE уже будут на пенсии.
Лучше оставить JEE в прошлом и начать разрабатывать новые системы более надежные, более поворотливые и более правильные, которым будет достаточно -Xmx=2G, чтобы поднять всю систему и чтобы она отлично при этом работала.
Если продолжить поддерживать JavaEE, то под нее будет развиваться новые библиотеки и легаси код будет рождаться со старта новых проектов.
Тот же Servlet API — это крайней не приятная технология, которая морально устарела, но продолжает развиваться.
JAX-RS — новая и удобная технология, которая базируется на том же Servlet API (нельзя просто взять и уйти от легаси).
Кстати, семантически ваш пример, это Node, Dict, Set или что?
И если на такие грабли можно наступить на столь элементарном примере, то на более сложном это может вылиться в множество потраченных минут / часов на поиск проблемы.
Вложите более-менее сложный YAML документ, как многострочное поле в AXON документе, который в свою очередь представлен в виде YAML, это вполне валидный кейс:
— вы записываете в файл данные, пришедшие извне, в формате AXON в представлении YAML, для удобства чтения.
Шутки про вложение XML в JSON (или даже JSON в JSON) смешные, пока не столкнешься с ними в реальном проекте.
— можно ли запихнуть XML в AXON?
— можно ли запихнуть JSON в AXON?
У нас системы общаются на базе AXON и нам нужно прокинуть в еще одну нашу систему XML (или JSON), который получили от пользователя.
или:
в зависимости от предпочтений, технических возможностей и ограничений.
При этом использовать стандарт разметки, которы поддерживается во всех языках и давно отлажен и отлично работает.
Но теперь нужно писать encoder / decoder для этого формата во всех частях системы на всех языках, которые в нашей системе будут и нам очень повезет, если у нас будет язык со слабой типизацией.
Но это уже трейдоф: решили проблему объема данных, заплатили написанием кастомного парсера.
Можно обойти, задав жесткий контракт:
Но семантика уже не та.
JSON имеет куда более неприятные особенности, чем приведенные в статье.
Как вариант, в JSON необходимо каждый раз указывать все имена полей в массиве однотипных объектов. Из-за этого объем json документа существенно увеличивается.
Убрать кавычки, если ключ имеет вид идентификатора — это существенное усложнение парсера, которое позволит сэкономить 20 символов для строки длинной в 300 символов.
К тому же из документации не понятно, можно ли кавычку " или какой-то спец.символ использовать как Ключ, как вариант для конфигурации автозамены.
первый вопрос на котором себя словил: three" — почему тут есть кавычки? это какая-то специальная пометка?
не сразу заметил, что это конец строки.
Вот любят возводить преимущества асинхронности в абсолют и совсем не обращать внимание на нюансы!
Асинхронность дает преимущество только для IO-bound операций. И при преобладающем количестве IO асинхронность будет рулить!
При CPU-bound операциях (сложная логика обработки данных из базы) при однопоточной модели event-loop лишь увеличивают задержку ответа.
пример: Два запроса с количеством CPU-bound операций N и K соответственно. Как ни крути, но выполнить меньше не получится. Время на выдачу первого ответа: time( N + K' ), второго: time( N' + K ), где N' и K' — это операции, которые будут выполнены благодаря переключению контекстов (асинхронно).
Если нагрузить NodeJS множеством длительных CPU-bound операций он будет обрабатывать запросы дольше, чем тот же PHP, который использует «железные» потоки.
Сравнивать PHP и NodeJS — это как сравнивать «теплое с мягким».
PHP — «живет, чтобы умирать», и в отличии от NodeJS из коробки не имеет ни пула воркеров, ни JIT, ни кешей.
У каждого из них свой путь чем-то лучше, чем-то хуже!
Objective-C ближе к Си, чем C++.
И вот статья о проверке Java, интересно что повлияло на изменение курса?
Боль и убытки приносят те джуны, которые начитались бложиков по развитию от 24-летних Синьеров, которые вечно трубят, что компания и девочки-hr'очки должны целовать песок по которому они (программисты) ходили, и проповедуют переходы между компаниями каждые полгода, чтобы повысить ЗП на 20-100%.
Но если не рассматривать таких джунов, то проблема до боли простая: Джун не знает/не понимает зачем ему нужен менторинг, зачем ему пилить этот бесполезный учебный проект, который он даже в резюме не добавит, и, более того, ему даже не пытаются объяснить этого.
Нужно заинтересовать джунов, а не просто сказать «компания тратит кучу денег на взращивание», после чего каждый остается при своем мнении: «Компания меня использует и не дает ничего взамен», «Это глупый джун, который не хочет работать, а компания из-за него страдает».
А ведь если разжевать скилы и поставить цели, дать нужный курс развития и объяснить Зачем нужна какая-то фича, пусть даже в тестовом проекте, то «Младшенькому» будет интереснее и это будет для него вызов, после которого он захочет еще и еще, а не «непроходимая стена» из-за которой он будет проклинать текущую компанию и искать новую.
в качестве примера:
Бекэнд джун (java, .net, ruby, php etc.), которому дают задачу запилить фронтенд часть (html + js), джун не понимает и не хочет делать фронтенд, он же бекэндщик. Но если ему объяснить, что качественную систему можно построить только если знаешь как работают все ее компоненты и как они коммуницируют, дополнив это тем, что это повысит его ценность и востребованность на рынке труда, а самое главное — рассказать, что эта задача ему поставлена, чтобы он получил опыт интеграции двух подсистем не был упертым девом: «вот мне это сложно сделать, делай это у себя», а задумывался о сложности реализации на какой-то из сторон.
Да и в целом когда кто-то говорит, что это не его дело — это дико раздражает, т.к. чаще всего это значит, что коллега просто не хочет работать (лучше ютубчик посмотреть).