image_2025-02-20_15-52-56.png
68.4 KB
Java vs Python, часть не помню какая)
Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.
Вот еще пример.
Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery
А что есть в Java? Есть ли что-то?)
BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.
Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)
#java #python #data_science
Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.
Вот еще пример.
Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery
А что есть в Java? Есть ли что-то?)
BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.
Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)
#java #python #data_science
👍2❤1🔥1
И снова AI агенты...
AI агент по определению должен делать что-то полезное, делать это с использованием AI, автономно и недетерминировано.
Сейчас я хочу рассмотреть свойство полезности.
AI агент в чем-то похож на умный proxy. Ум обеспечивает LLM (или не обеспечивает, тут идут споры))) ). А далее агент вызывает некую существующую функцию. Или несколько функций.
В терминологии AI это tool:
1) https://python.langchain.com/docs/concepts/tools/
2) https://docs.spring.io/spring-ai/reference/api/tools.html
tool - вообще говоря это просто метод Java, Python или любого другого языка, аннотированый соответствующим образом.
Как агент понимает, что умеет tool? Аннотации с описанием назначения тула, входных и выходных параметров.
Но если подумать - мы же живем в REST мире, в нем победил OpenAPI, а там вся необходимая информация есть. И текстовые описания, и граничные значения, и примеры. Даже адреса серверов на разных средах можно в спеке указать.
Нельзя ли это как-то переиспользовать? DRY все таки!
Можно. https://python.langchain.com/docs/integrations/tools/openapi/ на примере Python
Загружаем спеку, преобразуем в формат, понятный AI и создаем агента:
with open("spotify_openapi.yaml") as f:
raw_spotify_api_spec = yaml.load(f, Loader=yaml.Loader)
spotify_api_spec = reduce_openapi_spec(raw_spotify_api_spec)
...
spotify_agent = planner.create_openapi_agent(
spotify_api_spec,
requests_wrapper,
llm,
allow_dangerous_requests=ALLOW_DANGEROUS_REQUEST,
)
Почему не Java?
https://github.com/langchain4j/langchain4j/issues/1307
Ждем-с.
Что-то делается и для Spring AI, но пока сторонними разработчиками https://readmedium.com/connect-existing-openapis-to-llms-with-spring-ai-039ccabde406
Это самый простой способ вызвать существующий функционал.
Если он не подходит по одной следующих причин:
1) нет готового адаптера OpenAPI
2) нет OpenAPI спецификации, или она сделана криво, а доработка ее другой командой требует времени
3) хочется объединить несколько запросов в один tool или обогатить ответ tool-а локальной информацией
4) нужно убрать лишнее из ответа
то можно вернуться к исходному варианту - написать свой кастомный tool, возвращающий только то, что нужно и документированный так, как нужно.
Ну и третий вариант - отдельный MCP сервер https://t.me/javaKotlinDevOps/376.
У него два плюса:
1) MCP API - это специализированное API, адаптированное для использования LLM
2) tool-ом в виде MCP сервера может в теории воспользоваться любой AI агент
#ai #llm #spring #python
AI агент по определению должен делать что-то полезное, делать это с использованием AI, автономно и недетерминировано.
Сейчас я хочу рассмотреть свойство полезности.
AI агент в чем-то похож на умный proxy. Ум обеспечивает LLM (или не обеспечивает, тут идут споры))) ). А далее агент вызывает некую существующую функцию. Или несколько функций.
В терминологии AI это tool:
1) https://python.langchain.com/docs/concepts/tools/
2) https://docs.spring.io/spring-ai/reference/api/tools.html
tool - вообще говоря это просто метод Java, Python или любого другого языка, аннотированый соответствующим образом.
Как агент понимает, что умеет tool? Аннотации с описанием назначения тула, входных и выходных параметров.
Но если подумать - мы же живем в REST мире, в нем победил OpenAPI, а там вся необходимая информация есть. И текстовые описания, и граничные значения, и примеры. Даже адреса серверов на разных средах можно в спеке указать.
Нельзя ли это как-то переиспользовать? DRY все таки!
Можно. https://python.langchain.com/docs/integrations/tools/openapi/ на примере Python
Загружаем спеку, преобразуем в формат, понятный AI и создаем агента:
with open("spotify_openapi.yaml") as f:
raw_spotify_api_spec = yaml.load(f, Loader=yaml.Loader)
spotify_api_spec = reduce_openapi_spec(raw_spotify_api_spec)
...
spotify_agent = planner.create_openapi_agent(
spotify_api_spec,
requests_wrapper,
llm,
allow_dangerous_requests=ALLOW_DANGEROUS_REQUEST,
)
Почему не Java?
https://github.com/langchain4j/langchain4j/issues/1307
Ждем-с.
Что-то делается и для Spring AI, но пока сторонними разработчиками https://readmedium.com/connect-existing-openapis-to-llms-with-spring-ai-039ccabde406
Это самый простой способ вызвать существующий функционал.
Если он не подходит по одной следующих причин:
1) нет готового адаптера OpenAPI
2) нет OpenAPI спецификации, или она сделана криво, а доработка ее другой командой требует времени
3) хочется объединить несколько запросов в один tool или обогатить ответ tool-а локальной информацией
4) нужно убрать лишнее из ответа
то можно вернуться к исходному варианту - написать свой кастомный tool, возвращающий только то, что нужно и документированный так, как нужно.
Ну и третий вариант - отдельный MCP сервер https://t.me/javaKotlinDevOps/376.
У него два плюса:
1) MCP API - это специализированное API, адаптированное для использования LLM
2) tool-ом в виде MCP сервера может в теории воспользоваться любой AI агент
#ai #llm #spring #python
Docs by LangChain
LangChain overview - Docs by LangChain
LangChain provides create_agent: a minimal, highly configurable agent harness. Compose exactly the agent your use case needs from model, tools, prompt, and middleware.
👍1
Концепция venv (virtualenv) в Python
Концепция крутая, как по мне ноутбуки и виртуальные окружения - две самые крутые фичи в Python.
Если вкратце о ее сути: ты создаешь для каждого проекта отдельную виртуальную среду, со своим интерпретатором Python (разные версии) и своим набором библиотек.
Это удобно, и решает проблему конфликта зависимостей. Небольшое уточнение: если бы все сервисы и библиотеки явно указывали версии зависимостей - конфликтов бы не было, но мы же говорим о реальном мире.
К слову, концепцию позаимствовала и Java, я про jenv - https://t.me/javaKotlinDevOps/442 - правда, ограничить можно только версию Java.
Но блин.
Почему утилит, реализующих виртуальные окружения столько:
- venv
- virtualenv
- uv
- Poetry
- PDM
- Hatch
- Rye
- Conda
- Mamba
- Micromamba
- Pixi
- Pipenv
- pyenv-virtualenv
- virtualenvwrapper
- Tox
- Nox
- Devbox
- Flox
- Devenv.sh
- Spack
- Vex
????
Явная иллюстрация анекдота про 10 стандартов)
Ясно, что они не идентичны по функционалу.
1) кто-то добавляет возможность менеджера пакетов (и это правильно),
2) кто-то позволяет формировать список зависимостей проекта requirements.txt (и это тоже правильно),
3) кто-то добавляет возможность делать lock зависимостей (спорная фича IMHO).
Кто-то просто устарел. Кто-то заточен для тестов, где нужна куча разных сред. Кто-то просто добавляет небольшие фишки в другой менеджер, типа убирает необходимость явно включать использование виртуального окружения в консоли (activate).
Но все же...
Причем 4 из них имеют официальный статус)
P.S. Самой крутой и современной считается uv. На данный момент.
#python #java #virtual_env
Концепция крутая, как по мне ноутбуки и виртуальные окружения - две самые крутые фичи в Python.
Если вкратце о ее сути: ты создаешь для каждого проекта отдельную виртуальную среду, со своим интерпретатором Python (разные версии) и своим набором библиотек.
Это удобно, и решает проблему конфликта зависимостей. Небольшое уточнение: если бы все сервисы и библиотеки явно указывали версии зависимостей - конфликтов бы не было, но мы же говорим о реальном мире.
К слову, концепцию позаимствовала и Java, я про jenv - https://t.me/javaKotlinDevOps/442 - правда, ограничить можно только версию Java.
Но блин.
Почему утилит, реализующих виртуальные окружения столько:
- venv
- virtualenv
- uv
- Poetry
- PDM
- Hatch
- Rye
- Conda
- Mamba
- Micromamba
- Pixi
- Pipenv
- pyenv-virtualenv
- virtualenvwrapper
- Tox
- Nox
- Devbox
- Flox
- Devenv.sh
- Spack
- Vex
????
Явная иллюстрация анекдота про 10 стандартов)
Ясно, что они не идентичны по функционалу.
1) кто-то добавляет возможность менеджера пакетов (и это правильно),
2) кто-то позволяет формировать список зависимостей проекта requirements.txt (и это тоже правильно),
3) кто-то добавляет возможность делать lock зависимостей (спорная фича IMHO).
Кто-то просто устарел. Кто-то заточен для тестов, где нужна куча разных сред. Кто-то просто добавляет небольшие фишки в другой менеджер, типа убирает необходимость явно включать использование виртуального окружения в консоли (activate).
Но все же...
Причем 4 из них имеют официальный статус)
P.S. Самой крутой и современной считается uv. На данный момент.
#python #java #virtual_env
Telegram
(java || kotlin) && devOps
Жонглирование JDK
Иногда нужно вести разработку нескольких сервисов, требующих разных версий JDK. Или нескольких релизов одного и того же сервиса. Или какое-то ПО на компьютере требует одной версии JDK, а разработка другой.
Все эти проблемы решает утилита…
Иногда нужно вести разработку нескольких сервисов, требующих разных версий JDK. Или нескольких релизов одного и того же сервиса. Или какое-то ПО на компьютере требует одной версии JDK, а разработка другой.
Все эти проблемы решает утилита…
Медленная загрузка сервиса - значит Java?)
Есть такая проблема у Java, в частности при использовании Spring Framework. А точнее когда поверх Spring-а накручиваются свои компоненты.
Загружается куча классов, много кода инициализации = много времени. Как с этим борются - см. по тэгу #java_start_boost
Но только ли это проблема Java?
Запускал небольшую AI модельку на Python. Один скрипт. Скрипт стартует более 20 секунд.
Ну, думаю, модель так долго грузится. Померил - нет, модель порядка 3 секунд. Она уже в виде кэша скачана на локальный компьютер, да и не LLM это.
Антивирус? Интерпретатор Python?
Нет, всего лишь библиотека sentence-transformers.
На самом деле конечно не всего лишь. Она под капотом грузит движок для инференса - PyTorch. Плюс другие зависимости.
Но за 20 секунд старта ответственна именно строчка c импортом:
Тут еще видится "выстрелил" высокий уровень абстракции, принятый в Python.
Пишешь пару строк - у тебя все работает. Удобно? Да. Но есть нюансы)
Вывод - высокий уровень может превратится в айсберг. Ты видишь вершину, а под ней еще...
#python #java
Есть такая проблема у Java, в частности при использовании Spring Framework. А точнее когда поверх Spring-а накручиваются свои компоненты.
Загружается куча классов, много кода инициализации = много времени. Как с этим борются - см. по тэгу #java_start_boost
Но только ли это проблема Java?
Запускал небольшую AI модельку на Python. Один скрипт. Скрипт стартует более 20 секунд.
Ну, думаю, модель так долго грузится. Померил - нет, модель порядка 3 секунд. Она уже в виде кэша скачана на локальный компьютер, да и не LLM это.
Антивирус? Интерпретатор Python?
Нет, всего лишь библиотека sentence-transformers.
На самом деле конечно не всего лишь. Она под капотом грузит движок для инференса - PyTorch. Плюс другие зависимости.
Но за 20 секунд старта ответственна именно строчка c импортом:
from sentence_transformers import SentenceTransformer
Тут еще видится "выстрелил" высокий уровень абстракции, принятый в Python.
Пишешь пару строк - у тебя все работает. Удобно? Да. Но есть нюансы)
Вывод - высокий уровень может превратится в айсберг. Ты видишь вершину, а под ней еще...
#python #java
Кто же изобрел ноутбуки (Jupiter notebook)?
Ранее уже писал, что это питонисты, а точнее ML инженеры питонисты.
Выяснилось, что это не совсем так.
Дональд Кнут Грамотное программирование, 2001. Тот самый, что написал 3 тома Искусства программирования.
Собственно концепция грамотного программирования - это писать код для людей, а не для машин. Т.е. в формате рассказа, где главный - текст.
Т.е не
а скорее
А код - это переменная, которую можно переиспользовать.
При нужны соответствующие правила форматирования и движок для рендера всего это в удобочитаемый вид.
Кнут предлагал его всем разработчикам, взяли только дата сатанисты) Но с развитием AI может и пошире распространится)
Плюс понятен - читаемость. Минус - сложнее (дольше) писать. Мы же вообще уходим от документации к самодокументирующемуся кода. Но для сложного кода кажется смысл в нем есть.
#python #notebooks
Ранее уже писал, что это питонисты, а точнее ML инженеры питонисты.
Выяснилось, что это не совсем так.
Дональд Кнут Грамотное программирование, 2001. Тот самый, что написал 3 тома Искусства программирования.
Собственно концепция грамотного программирования - это писать код для людей, а не для машин. Т.е. в формате рассказа, где главный - текст.
Т.е не
// Используем метод сортировки пузырьком, суть которого...
// Декларация метода:
void boubleSort(int[] array) {
...
а скорее
Используем метод сортировки пузырьком, суть которого...
Декларация метода:
@sort_method =
void (int[] array) {
...
@
А код - это переменная, которую можно переиспользовать.
При нужны соответствующие правила форматирования и движок для рендера всего это в удобочитаемый вид.
Кнут предлагал его всем разработчикам, взяли только дата сатанисты) Но с развитием AI может и пошире распространится)
Плюс понятен - читаемость. Минус - сложнее (дольше) писать. Мы же вообще уходим от документации к самодокументирующемуся кода. Но для сложного кода кажется смысл в нем есть.
#python #notebooks
Почему в Python "неправильная" документация.
Если посмотреть библиотечный Python код, то там можно увидеть вот такое:
Или такое:
Что-то к так с документацией, да?)
Зачем питонисты решили сделать все наоборот - комменты после кода???
До кода же логичнее - вначале читаешь доки, потом если надо смотришь код?
Не от балды, нет.
Интерпретатор при загрузке модуля читает первое выражение в теле класса/функции/метода и, если это строковый литерал, помещает его в атрибут ___doc___ соответствующего объекта. Работает принцип convention over configuration.
Также документация выводится с помощью метода help(obj) - если надо прямо в коде. Или через рефлексию - inspect. Или с помощью CLI утилиты pydoc.
Описывается формат документации стандартом PEP 257. Т.е. все продумано.
Причём поля класса документируются точно также для единообразия. Хотя на них стройная система, описанная выше рушится.
И появляется интересный нюанс - если по привычке писать документацию к полям в JavaDoc стиле, то она сопоставится с другим полем)
Мне конечно привычнее JavaDoc стиль, но признаю красоту идеи с автоматическим обогащением метаданных сущности документацией, причём средствами языка.
P. S. Как я обратил на это внимание? Один агент написал документацию в формате JavaDoc, другой на ревью заметил, что это не по стандарту Python)
#lang #python #java #conv_over_conf
Если посмотреть библиотечный Python код, то там можно увидеть вот такое:
class IntervalArray(IntervalMixin, ExtensionArray):
"""
Pandas array for interval data that are closed on the same side.
Или такое:
@classmethod
def _validate(cls, left, right, dtype: IntervalDtype) -> None:
"""
Verify that the IntervalArray is valid.
Что-то к так с документацией, да?)
Зачем питонисты решили сделать все наоборот - комменты после кода???
До кода же логичнее - вначале читаешь доки, потом если надо смотришь код?
Не от балды, нет.
Интерпретатор при загрузке модуля читает первое выражение в теле класса/функции/метода и, если это строковый литерал, помещает его в атрибут ___doc___ соответствующего объекта. Работает принцип convention over configuration.
Также документация выводится с помощью метода help(obj) - если надо прямо в коде. Или через рефлексию - inspect. Или с помощью CLI утилиты pydoc.
Описывается формат документации стандартом PEP 257. Т.е. все продумано.
Причём поля класса документируются точно также для единообразия. Хотя на них стройная система, описанная выше рушится.
И появляется интересный нюанс - если по привычке писать документацию к полям в JavaDoc стиле, то она сопоставится с другим полем)
Мне конечно привычнее JavaDoc стиль, но признаю красоту идеи с автоматическим обогащением метаданных сущности документацией, причём средствами языка.
P. S. Как я обратил на это внимание? Один агент написал документацию в формате JavaDoc, другой на ревью заметил, что это не по стандарту Python)
#lang #python #java #conv_over_conf
Рубрика: "Полезное из Python"
Как вы думаете, что делает команда:
Ответ не очевиден (для меня): выводит 20 наиболее медленных тестов.
Вот так бы было более очевидно:
Второй вопрос: что меня в этом больше всего расстраивает?)
Ответ: то, что ни в Maven, ни в Gradle тестовых плагинах ничего такого нет. Хотя можно легко завайбкодить с помощью AI.
Если быть точным: в Gradle легко, в Maven придется плагин или внешний скрипт писать.
P.S. Еще такой же паттерн использует PostgreSQL -
#python #junit #unit_tests
Как вы думаете, что делает команда:
uv run pytest --durations=20 ?Ответ не очевиден (для меня): выводит 20 наиболее медленных тестов.
Вот так бы было более очевидно:
uv run pytest --durations-min=1.0Второй вопрос: что меня в этом больше всего расстраивает?)
Ответ: то, что ни в Maven, ни в Gradle тестовых плагинах ничего такого нет. Хотя можно легко завайбкодить с помощью AI.
Если быть точным: в Gradle легко, в Maven придется плагин или внешний скрипт писать.
P.S. Еще такой же паттерн использует PostgreSQL -
FROM pg_stat_statements
ORDER BY total_exec_time DESC, а еще есть slow query log с фильтрацией по предельной длительности#python #junit #unit_tests