Говорим о книжке больше, чем о самой Java. Мне больше интересны подходы (AOP, DI и пр), применимые плюс-минус ко всем языкам, а не конкретные реализации в Java, современной или не очень.

Работают. VScode умеет в WSL работать. Хотят там проекты, а из под винды запускают VSCode и кодируют.

Возможно! На какую тему вам бы хотелось:)?

пока нет

@@t0digitalКак справляетесь с зависимостями? Хотелось бы видео об этом с примерами)

Спасибо, интересная статья

Следите за обновлениями. Возможно уже в декабре

@@t0digital Отлично

Yep:)

@@t0digital это наша общая задача )) кстати, для меня сработала такая фишка, что решил утром первым делом делать тренировку, прямо без размышлений в 9 утра кинул коврик и погнал, потому что иначе, если оставлять на день или на вечер, то НИХРЕНА до тренировки не добираешься )))

@@indigoram89 спасибо за мысль, да! Надо надо:)

Явное лучше неявного согласно Zen of Python, с этой точки зрения явный декоратор лучше неявного расколбаса, который где-то навешивается:) С другой стороны логика в этих декораторах (явных или нет) должна быть вспомогательной, и если неявный подход применяется, все разработчики в команде все равно о нем должны знать. Если так, то может и неявное заведение это ок. Пушка да) не нравится эхо на записи, если пушка ближе к источнику звука, эхо меньше пишется

J2EE тулзы разрабатывает Eclipse Foundation. Spring поставляют Pivotal.

@@galua и многое платное от Oracle. Во всяком случае в мои времена так было, вероятно в больших интеграторах по-прежнему

@@t0digital на данный момент Oracle барыжат своей JDK, которую они сделали платной. Хотя непонятно кто это покупает, когда есть бесплатные JDK куда лучше. Плюс Oracle в саппорт своей БД ушли. Сейчас это их основное направление продаж. К J2EE (Jakarta) они уже почти никакого отношения не имеют.

@@galua мне кажется они столько своего напродавали, что это не умерло так быстро. Webcenter, ADF их, интегрированные ECM, BPM и тп. Но хз. В России понятно, что каюк этому всему уже)

Можно и просто конфиг-файл, но тогда мысли такие: - хотим обеспечить переключение разных конфиг-файлов - хотим обеспечить подключение разных конфиг-файлов одновременно, в пределах интерпретатора - не хотим дублировать import парным присвоением, значит переносим присвоение внутрь импортируемой части - хотим отследить конфликтующие присвоения - хотим отследить обращения до присвоения Я сам в python DI не использовал. Там, где я использовал: - в репозитории тысячи файлов и десятки конфигураций - строгая статическая типизация - аннотирую конструкторы классов, ставлю типы аргументов; эти конструкторы руками не вызываю; DI сам создает граф объектов

relative numbers, показывают на сколько строк вверх или вниз надо сдвинуться, чтобы попасть на конкретную строку. Хотя я не могу сказать, что я к этому привык и передвигаюсь по привычке на глаз, не смотря на эти номера)

Ну вот суть AOP в этом и есть. Именно такая - какая-то падла где-то пропатчила класс и пойди ищи, где это произошло:) Явный декоратор с этой точки зрения лучше. Но тогда надо не забывать его ставить. Один пропущенный декоратор на права доступа может открыть конфиденциальную информацию для сторонних пользователей, например. С другой стороны этот патчинг должен добавлять функционал, не изменять/удалять его. Например, логирование, проверка прав доступа, что-то такое. Если разработчик знает, что на проекте такой подход практикуется, то в целом норм.

@@t0digital пропущенный декоратор на раз выявляется unit тестами, а подобный импорт hackit, который даже не используется в коде, можно будет найти только с помощью дебага, а так фиг поймёшь, откуда там взялось это декорирование.

@@suhanoves может да, а может и нет - зависит от реализации и документирования. Что-то неявное-то оно всегда есть. Фреймворк любой - это и есть неявное. Ты опираешься на те конструкции, что предоставил тебе фреймворк. А там проверки внутри разные, помогатели, middlewares те же. Ты отдаешь что-то одно, а одна из middleware это меняет - тоже неявное вроде как, но просто если ты пользуешься фреймворком, то должен об этом знать. Так же и с AOP. Джанговые сигналы - отличный пример неявного.

точняк:)))

Но как только JDK и JRE отпоили валерьянкой и успокоили, в помещение, не заметив на крыльце нервно курящую с обиженным лицом JPA, шумно открыв дверь с ноги, влетели возмущенные JCP и JSR ))

А где я говорю, что джава неактуальна? Тайм код пришлите, пожалуйста, где я это говорю? То, что джава в топе - это не так. Посмотрите график tiobe по java www.tiobe.com/tiobe-index/java/ График на уменьшение. И в целом рейтинг языков на tiobe: www.tiobe.com/tiobe-index/ В топе там Python. Это объективные цифры, не мои фантазии - даже если вы с ними лично не согласны.

@@t0digital этот индекс - всего лишь поисковый рейтинг. Не очень представляю, как по нему можно судить о чем-то кроме интереса к языку программирования со стороны Интернета. Интерес к Python объясняется, скорее всего, тем, что с ним сталкиваются не только программисты. Это прикладной язык для анализа данных, его часто используют для обучения основам. Его легко развернуть (anaconda, jupyter) и начать. Инфоцыгане, опять же, славят легкий вход, наплодили кучу "курсов" и раскидали рекламу. Вот язык и в топе.

@@bobrakaubamha6265 я не уверен, что курсов по джаве меньше, чем по питону, аналитики у меня нет, а у всех Гб/скилбокс/практикумов/отусов и прочих вполне себе и курсы по джаве, и курсы по питону. Судить о популярности технологии по поисковым запросам можно. Чем люди пользуются, о том и ищут. Если поисковых запросов по Algol86 мало, это вполне себе говорит о том, что Algol86 не так чтобы сильно популярен:)

@@t0digital о популярности судить можно. Я, собственно, об этом же говорил. Вот только популярность не свидетельствует ни о качестве, ни о действительной распространенности технологии. Пример - php. Как технология, php стал гораздо лучше, чем был, а популярность снизилась, хотя софта написано много.

@@bobrakaubamha6265 ну так я и говорю о популярности=актуальности. Вполне возможно Algol86 на три головы круче джавы, но на нём пишут полтора человека и это стоит иметь в виду.

DI в питоне и в других ЯП выполняет одни и те же задачи, позволяет изменять поведение класса без изменения самого класса и упрощает юнит тестирование заменой реального внедряемого объекта его простенькой тестовой копией. DI возможен и без контейнера специализированного

@@t0digital но в Python мы можем достичь этого и без DI. Внешнее управление зависимостями, в целом, подход местами незаменимый, особенно если у нас что-то вроде конечных автоматов или всякой другой сложной бизнес-логики. Но, например, ваш пример из видео проще и логчнее решить через миксин-наследование.

@@trankov Если mixin у вас является базовым для сотни разных наследников, то при его замене вам в любом случае придется изменить их декларацию в сотне разных мест, тщательно стараясь при этом ни одного не забыть, чтоб не оставить случайно этому классу предыдущее поведение. В случае DI вы просто меняете одну строчку в объявлении бина - и всё, в общем случае абсолютно все использующие его участки кода получают новую реализацию. Бывают, конечно, всякие извращенные ситуации - например, когда часть классов должны использовать старую версию, часть новую, а часть сразу обе. Но в этих случаях с mixin'ами все будет, скорее всего, даже еще запутаннее.

@@MT-fy9zz звучит очень убедительно, но явно где-то подвох) надо подумать. Спасибо за понятный ответ.

Как мы в питоне можем достичь этого без DI? Я не о DI-контейнере, я а самом DI. Наследование почти всегда зло, композиция лучше наследования, композиция это как раз про DI. Наследование это часто попытки наследовать кролика от вертолёта, чтобы переиспользовать что-то от вертолёта в кролике. Композиция это, например, передача нужного функционала вертолёта в конструктор или какой-то setter кролика. Легче тестировать, нет логических проблем с тем, что кролик не является вертолётом

Тоже не особо понял в чем смысл контейнера в данном примере. По-моему ничем не отличается от того, чтобы положить нужный нам объект в переменную

@@r735g3 punq может резолвить зависимости от зависимостей. Например, MailProvider сам может от чего-то зависеть и все эти зависимости внутри себя разрулит punq. Пример есть в их доке: class ConfigReader: def get_config(self): pass class EnvironmentConfigReader(ConfigReader): def get_config(self): return { "logging": { "level": os.env.get("LOGGING_LEVEL", "debug") }, "greeting": os.env.get("GREETING", "Hello world") } container.register(ConfigReader, EnvironmentConfigReader) class Greeter: def greet(self): pass class ConsoleGreeter(Greeter): def __init__(self, config_reader: ConfigReader): self.config = config_reader.get_config() def greet(self): print(self.config['greeting']) container.register(Greeter, ConsoleGreeter) container.resolve(Greeter).greet() Тут ConsoleGreeter зависит от ConfigReader, и punq сам разрулит эту зависимость.

Подписка. Примерно по книге в месяц будем читать. 18 декабря новая книга.

hackit это минимальный пример, демонстрирующий принцип, а не финальная реализация, готовая к тому, чтобы пойти в продакшн. Конечно, должен быть реализован гибкий декларативный механизм регистрации такого поведения, в духе: Aspecter.register(in_objects=(Something,), name_pattern=""^fo"", pre_function=log_before, post_function=log_after) Конечно, регистрация такой сквозной логики должна происходить где-то наверху при инициализации - задолго до реального вызова Something и других аналогичных классов. Мне было важно показать принцип того, как можно навесить вспомогательную логику на уже имеющуюся бизнес-логику без правки этой бизнес-логики, а не писать полный готовый к продакшн пример.

Большое спасибо за комментарий, пошел думать-читать

где?

понимаю:) класс на 2к строк в любом ЯП это страшно

у нас в легаси проекте код с классом на 27 тысяч строк и методами по 1-3к Здоровья вам Игорь.

@@Ca1vema и я вам сочувствую. Благо мне ток показали чужой легаси. Мне его не править. Мой легаси полегче успешно переписываю на fastapi)

Специальное такое:)

дом Алексея видимо. Пора хаус-тур видео сделать)

Можно писать хорошо и без ООП, можно писать плохо и с ООП, да и ООП бывает разным, в go/rust нет наследования, но есть объекты, является ли это ООП? С какой-то точки зрения да, с какой-то - нет, однако сразу все эти классические фентифлюшки с наследованием идут лесом)

@@t0digital Наследование стоит использовать только в крайнем случае, полагаю, это нормально. Плохо с ООП - это не ООП, в строгом смысле.

@@t0digital Нет, нпличие объектов - не гарантирует ООП в современном понимании.

@@sergzach ну значит в двух популярных современных ЯП осознанно нет ООП и это прекрасно.

@@t0digital Ничего хорошего. Пишут тут, понимаешь, много кода безо всякой системы, посмотришь на это - задачи не хочется брать, до того все нестройно.

Это на батхёрт. Я спокойно отношусь ко всем ЯП. Писал на Java, работал в Oracle. Везде есть минусы, в питоне в том числе. Километровые XML конфиги это не есть хорошо в любом случае. Хотя судя по всему современная java уже отошла от них. Но не думаю, что далеко, DNA уже такой)

@@t0digital ну тут как посмотреть: энтерпрайз не слишком-то податлив, поэтому новые версии языка крайне медленно адаптируются, но этих версий клепают сейчас по две в год. Только и успеваем облизываться на новый синтаксис и фичи

@@antondoronin1261 Вопрос в том, что реально дает этот синтаксис? Нам, разрабам то, понятно хочется свежей струи, чего то новенького так сказать. Я только за. Но если смотреть по сути, не обрастет ли тот же Питон тоннами фреймворков и библиотек с разными акронимами, если займет место Джавы? И насколько будет просто поддерживать, именно поддерживать это все долгие годы. Пока что это java в основном. Питон пока видится больше как специфический DSL, для определенных областей. На котором можно например написать специфические сервисы, за счет наличия большого кол-ва специфических библиотек. Тот же AI. Как возможность катать какой то тулинг для разработки и администрирования. Например Си/Си++ так и не ушел окончательно из профессиональных десктопных инструментов, как его не пытаются подвинуть. Обычно все самое вкусное, ну или большинство, скажем так, до сих пор написано на этом языке. Наоборот, есть десктопные приложения которые пытались, и даже в нечто выросли, но так в итоге застряли как некая нишевая альтернатива, которой кто то время от времени пользуется. (Если смотреть на мейнстрим то толковых контрпримеров единицы. У меня на уме только IDEA да VS Code. Но тут у многих людей начинаются претензии к потребляемым ресурсам. Я уже не говорю за такие вещи как 3D и 2D редакторы какие то, игровые движки). Поэтому и с джавой будет так же. Кстати, вот писать энтерпрайз на Си++, по рассказам очевидца, то еще веселье. Тем более говорят есть места на этой планете, где до сих пор люди пользуются и поддерживают программы на COBOL. А мы джаву тут решили уже списать, со счетов ))) В общем это заблуждение считать что синтаксис все решает. Есть дофига еще важных моментов, которые должны быть обеспеченны, чтобы технология виделась надежной, не сильно рискованной, с хорошей поддержкой на долгие годы и было желание вкладывать огромные бабки, не беспокоясь что завтра они превратятся в тыкву. А с другой стороны это инертность, когда надежный инструмент и технологии есть, пусть и с какими то проблемками больше внутреннего характера. Тем более попа боль по поводу отсутствия какого то синтаксиса переживает не бизнес. PS: Кстати, да тоже хотел сказать, что современный энтерпрайз это уже далеко не J2EE. Есть аннотации, есть как минимум спринг контейнер, есть суппорт многих вещей надежными командами, что снимает нагрузку с разрабов бизнес апликейшена, а это немаловажно. А ошибки, так они везде есть, это же не потому что акронимов много. А вообще растет из нижних слоев, например таких как прямая работа с памятью и арифметика указателей в библиотеках Cи рантайма, на котором написано большинство современных языков и виртуальных машин, если не все так или иначе. В этом смысле джава вряд ли позволяет больше чем может позволить сишная либа под капотом. Питон тоже активно юзает сишный слой, всякие байндинги там. И я думаю что в нем тоже что то будет находится.

без километровых XML:)?

@@t0digital естественно. XML-конфиг теперь это моветон. Позови в видос, расскажу :)

@@galua помню как лет 10 назад один парень из нашего отдела, где я работал, предлагал затащить спринг в проект и старожилы говорили ну нэээт ты штооо:) должно быть, сейчас этот парень счастлив:)

@@t0digital нормальным Spring стал в 2013, когда появился Spring Boot. А сам по себе Spring - это просто DI-контейнер. Ещё был Spring MVC (до сих пор есть), но про это я вспоминать не хочу) А парня не зря старожилы отговаривали. 10 лет назад захлебнулись бы.

Ещё как пишут. Тащат старый j2ee дальше и дальше. Привет продуктам IBM. Стандарт xml и soap живут в корпоративных системах и изжить это невозможно.

Да, понимаю:) Но я вроде мягенько, только на основе своего опыта и Чистого кода. Сейчас, пишут тут в комментах, километровые XML конфиги в Java уже моветон, J2EE убит, а Spring конфетка. Проверять я это, правда, не хочу:)

@@t0digital а зря "не хочешь проверять". Spring boot реально изменил подходы))