Первый, ребята не с той стороны заходят, если вопрос подписок на сборки, то идти надо в сторону репозиториев эти сборки раздающих, ну например в maven central для java/kotlin и там просить создавать подписки, но я уверен эти репозитории тут же начнут интересоваться, а с чего бы им тогда бесплатно сборки хостить. И мы из опенсорса получим обыкновенный бизнес.
Второй, пока тебе не платят денег с тебя никто не спрашивает за качество и корпорации не могут тебе предъявить за уязвимости в твоем коде, или коде библиотек, которые ты использовал. Но, стану ли я, как корпорация платить за код, в котором возможно есть баги или уязвимости? А если и стану я бы потом хотел в судебном порядке предъявить тому, кто лишил меня пары миллионов
В заключении, если такая инициатива пройдет, то есть подозрение, что дело не выгорит, потому что корпорациям будет проще взять код в реп и самостоятельно собирать с учетом своих требований к безопасности - те заявленной фичи, чтобы чужой труд не использовался задарма ради получения прибыли мы так и не получим
Про Твиттер не знаю, если поделитесь источником, где указано, что именно так и поступили его создатели буду благодарен, хороший аргумент для споров с начальством по этому поводу.
И, поскольку вас забанили в редакторе кода и отобрали последний, доставшийся вам от деда, деревянный JDK, вы забили на решение, которое более 25 закалялось в боях
Подозреваю, что вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами. Но фраза "Мне не хватило понимания:" относилась к моей оценке статей, на которые я ссылаюсь, а не к моему пониманию того, как работает AspectJ. Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье. Моя статья не про AspectJ, поэтому я не занимаюсь в ней его детальным описанием.
просто написали враппер вокруг (дайте подумать) — прямого вызова функции!
Так точно, именно это я и сделал! Потому что враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей - например написать простые обработчики ошибок, чтобы убрать по всему коду try-catch, чтобы снизить когнитивную сложность кода. Или добавить не функциональных требований к вызовам функций, не изменяя их кода, написанного не мной, с минимальным риском попортить функциональные требования для которых писалась эта функция. В статье приведен пример простейшего использования этого чудесного, на мой взгляд, механизма, который не заслужил достойного к себе внимания.
Либо я чего-то не понял, либо вы какой-то pipeline-фреймворк навелосипедили.
Да, вообще-то я ничего и не велосипедил. Целью статьи было показать как с помощью ссылок на методы можно повысить гибкость в программе на примере одной простой штуки, которую я собрал, не претендуя на какое-либо новаторство. Я вообще считаю, что ссылки на методы незаслуженно мало используются при проектирование кода. А в заключение заметил, что с помощью даже такой простой штуки можно много каких вещей наворотить вокруг.
Так и не понял при чем здесь AspectJ был
Он был в списке инструментов, которые я посмотрел, и отметил что он может и почему он мне не подходит не более того, а также подчеркнул, что несмотря на это существуют ситуации где его использование оправдано.
Он так назван, потому что вызов всей цепочки собранной тоже в нем. Возможно есть смысл разделить сборку и исполнение, ну и названия соотвествующие сделать. Спасибо за предложение.
Согласился бы с этим утверждением, если бы речь шла об AspectJ именно этот его недостаток привел меня к идее реализовать подобную механику. Однако здесь вызов основного метода и всех вспомогательных ищется точно также, как если бы он вызывался напрямую за счет ссылок на методы. В конечном итоге сложность не выше, чем если бы все эти методы вызывались бы просто последовательно из другого метода. А преимущество заключается в том, что сам MethodExecutor является объектом и к нему можно применить порождающие паттерны проектирования, сократив дубликацию кода.
Да, обе эти задачи решаются с помощью данной механики. Разделение слоев мы уже решили через единую точку входа и выхода из бизнес логики. А чтобы добавить вторую, нужны дополнительные организационные и технологические ухищрения: возможность конфигурации secondary adapter'ов (из терминологии гексогональной архитектуры) и отсутствие прямых вызов из сервиса в сервис или сервиса в домен
Не могу не согласится с автором статьи, по теме жути, которая творится при использовании Spring JPA/Hiber, но поддержу и комментаторов, проблема не в них, я как-то делал свой ORM - это лучший способ понять почему hiber делает так как делает. Сначала все просто, но потом начинаешь добавлять нужную функциональность, обрабатывать краевые случаи, оптимизировать производительность и вот у тебя уже такой монстр с теми же проблемами. А в реальности все дело в JPA, как в спецификации, так что при разработке следующего метода получения данных из БД я от него ушел и копнул глубже. А дальше как в старом анекдоте "чертова гравитация"
Вижу 2 интересных аспекта:
Первый, ребята не с той стороны заходят, если вопрос подписок на сборки, то идти надо в сторону репозиториев эти сборки раздающих, ну например в maven central для java/kotlin и там просить создавать подписки, но я уверен эти репозитории тут же начнут интересоваться, а с чего бы им тогда бесплатно сборки хостить. И мы из опенсорса получим обыкновенный бизнес.
Второй, пока тебе не платят денег с тебя никто не спрашивает за качество и корпорации не могут тебе предъявить за уязвимости в твоем коде, или коде библиотек, которые ты использовал. Но, стану ли я, как корпорация платить за код, в котором возможно есть баги или уязвимости? А если и стану я бы потом хотел в судебном порядке предъявить тому, кто лишил меня пары миллионов
В заключении, если такая инициатива пройдет, то есть подозрение, что дело не выгорит, потому что корпорациям будет проще взять код в реп и самостоятельно собирать с учетом своих требований к безопасности - те заявленной фичи, чтобы чужой труд не использовался задарма ради получения прибыли мы так и не получим
Про Твиттер не знаю, если поделитесь источником, где указано, что именно так и поступили его создатели буду благодарен, хороший аргумент для споров с начальством по этому поводу.
Подозреваю, что вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами. Но фраза "Мне не хватило понимания:" относилась к моей оценке статей, на которые я ссылаюсь, а не к моему пониманию того, как работает AspectJ. Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье. Моя статья не про AspectJ, поэтому я не занимаюсь в ней его детальным описанием.
Так точно, именно это я и сделал! Потому что враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей - например написать простые обработчики ошибок, чтобы убрать по всему коду try-catch, чтобы снизить когнитивную сложность кода. Или добавить не функциональных требований к вызовам функций, не изменяя их кода, написанного не мной, с минимальным риском попортить функциональные требования для которых писалась эта функция. В статье приведен пример простейшего использования этого чудесного, на мой взгляд, механизма, который не заслужил достойного к себе внимания.
Да, вообще-то я ничего и не велосипедил. Целью статьи было показать как с помощью ссылок на методы можно повысить гибкость в программе на примере одной простой штуки, которую я собрал, не претендуя на какое-либо новаторство. Я вообще считаю, что ссылки на методы незаслуженно мало используются при проектирование кода. А в заключение заметил, что с помощью даже такой простой штуки можно много каких вещей наворотить вокруг.
Он был в списке инструментов, которые я посмотрел, и отметил что он может и почему он мне не подходит не более того, а также подчеркнул, что несмотря на это существуют ситуации где его использование оправдано.
Он так назван, потому что вызов всей цепочки собранной тоже в нем. Возможно есть смысл разделить сборку и исполнение, ну и названия соотвествующие сделать. Спасибо за предложение.
Согласился бы с этим утверждением, если бы речь шла об AspectJ именно этот его недостаток привел меня к идее реализовать подобную механику. Однако здесь вызов основного метода и всех вспомогательных ищется точно также, как если бы он вызывался напрямую за счет ссылок на методы. В конечном итоге сложность не выше, чем если бы все эти методы вызывались бы просто последовательно из другого метода. А преимущество заключается в том, что сам MethodExecutor является объектом и к нему можно применить порождающие паттерны проектирования, сократив дубликацию кода.
Да, обе эти задачи решаются с помощью данной механики. Разделение слоев мы уже решили через единую точку входа и выхода из бизнес логики. А чтобы добавить вторую, нужны дополнительные организационные и технологические ухищрения: возможность конфигурации secondary adapter'ов (из терминологии гексогональной архитектуры) и отсутствие прямых вызов из сервиса в сервис или сервиса в домен
Спасибо. Рад, что у меня получилось объяснить идею простым языком.
Не могу не согласится с автором статьи, по теме жути, которая творится при использовании Spring JPA/Hiber, но поддержу и комментаторов, проблема не в них, я как-то делал свой ORM - это лучший способ понять почему hiber делает так как делает. Сначала все просто, но потом начинаешь добавлять нужную функциональность, обрабатывать краевые случаи, оптимизировать производительность и вот у тебя уже такой монстр с теми же проблемами. А в реальности все дело в JPA, как в спецификации, так что при разработке следующего метода получения данных из БД я от него ушел и копнул глубже. А дальше как в старом анекдоте "чертова гравитация"