Information
- Rating
- 131-st
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Backend Developer
Middle
From 250,000 ₽
Java
Java Spring Framework
Spring Boot
PostgreSQL
Kubernetes
Apache Kafka
Greenplum
ETL
SQL
RabbitMQ
Большое спасибо за комментарий, могу вынести общее замечание к своему материалу: более ясно выразить глубину "копания" в обозначенном направлении. Действительно, указав в разделе "сети" DNS, подразумевается скорее понимание роли и применение протокола в области. Как и с connection pool, почему его раздувание — плохо, и какая роль у HikariCP — что и как он оптимизирует.
В целом, тем, согласен, много, но выше в комментариях, я описал что есть такое сеньор и нехватка хардов для специалиста — это не всегда главное узкое горлышко для повышения грейда. Да и рынок диктует свои правила, требования всегда росли и продолжают расти.
Полностью разделяю вашу позицию по поводу километровых книг, среднестатистическому разработчику читать их скорее вредно, чем полезно.
Хороший вопрос, сеньор — эксперт предметной области, он и в бизнесовое обсуждение может внести лепту, и организовать работу команды, и оценить нужно ли функционал реализовывать в целом, если подобное уже реализовано или есть подходящие для этого технологии. Junior и Middle — это про ответственность за задачи, а сеньор - про ответственность за разработку в проекте в целом.
Сеньор — это про опыт решения бизнес проблем, большую ответственность, и в меньшей мере про харды.
Чек-лист для движения от младшего специалиста к Миддлу. То есть Junior разработчик, который подтянет темы и навыки описанные в статье — смело может считаться средним специалистом Java-разработки.
Сами материалы и ресурсы, которые я собрал в формате дорожной карты, разместил по ссылке.
Статью можно интерпретировать как чек-лист с темами и обоснованием их изучения, понимание которых в наших реалиях неплохо бы сформировать. Знаю множество людей для которых подобный формат был бы полезен, я и сам сталкивался с проблемой нечёткости картины движения на этом пути.
LLM при написании статьи не использовалось в качестве источника информации. И отмечу, что цели ужать в одну статью в рассказ о каждой технологии не было, это получилась бы летопись.
Вместо этого, планируется выпускать небольшие статьи на каждую из тем, чтобы "магические" названия технологий, превратились в знакомые инструменты каждому.
Большое спасибо за комментарий
Теперь выложил, время публикации сдвинулось — не уследил) Приятного прочтения!
Лишь бы у Unfrozen всё успелось и мы поиграли в Olden Era в этом году)
Попробуй воспользоваться методами повышения качества приведёнными в статье, гибридный поиск - тоже хороший вариант, тот же самый elasticsearch можно использовать
Обучить и дообучить сложновато и дорого, для меня пока эта задача покрыта мраком.
В целом, rag отличная вещь, за свою ресурсную стоимость must have.
Возможно, попробую когда-нибудь doctovec, а так - альтернатив море
Spring AI умеет работать и on-prem через Ollama или интеграцию с локальными моделями, кроме того в qdrant есть свой трансформер, но он уступает в качестве. Либы вроде ml4j подключать не нужно, достаточно готовых адаптеров. По требованиям к железу не подскажу, зависит от модели. Параллелится без проблем на большинстве компонентов.
Просто на этот вопрос не ответить, слишком много переменных. Необходимо глянуть разные лидерборды, и оценить свою систему. Подумать над "перспективами" выбранной модели. Для локального размещения хороши последние версии Ollama и Mistral, из облачных выбирать из всего что на слуху и к чему есть доступ)
Большое спасибо, согласен, что нюансы от системы к системе бывают разительны.
Лучшим донатом за статью для меня - рассказать своим коллегам и друзьям о ней:)
Косвенно изобразил разбиение на чанки в схеме с порядком обработки документа, а так, согласен с вами полностью
В планах покрыть эту тему целиком, но в ближайшее время будет статья на другую тему, не менее интересную)
Для Kafka передавал JWT в хедерах, для gRPC через интерцептор, заполняя метаданные
https://habr.com/ru/companies/ruvds/articles/912502/
Вышла вторая часть с небольшой задержкой)
https://github.com/br0mberg/SupportDesk-IncidentService
Привет, и вышла вторая часть в профиле
https://github.com/br0mberg/SupportDesk-IncidentService
и вторая часть этой статьи вышла в профиле
Всё так, docker образ использовал с ним, пример на github по ссылке в статье, а рассказал про ZooKeeper, так как по сей день используется в legacy
Спасибо, к началу февраля планировал
Да знает, поскольку маппинг не следует производить на контроллере. Контроллеры должны быть максимально простыми, отвечая за прием запросов и формирование ответов. Путаницы с изоляцией слов в приложении нет. Действительно, можно добавить ещё слой презентатора, например, но наличие этого в статье для начинающего разработчика избыточно, увы). Рад что вы так серьёзно подошли к обсуждению материала)