Данная статья служит двум целям, быстро освежить знания по ООП и SOLID, а также полезно и весело по‑проектировать роботов с элементами игры средствами языка Java. Итак, Объектно‑Ориентированное Программирование (ООП).
Рассмотрим сначала основные четыре аспекта ООП:
Абстракция
Наследование
Инкапсуляция
Полиморфизм
Итак начнем проектировать наших роботов с учетом ООП.
Писать и организовывать код — это лучшее, что я умею. Код как хобби за более чем 15 лет в индустрии оставил за собой кладбище пет-проектов. К чему-то банально угасал интерес, что-то переставало быть актуальным, что-то делалось просто чтобы потренироваться, в чём-то было лень разбираться после перерыва — итог всегда один.
Недавно я разбирал истории CVE, связанные с завершением поддержки Tomcat 8.5, и решил посмотреть на Spring Boot 3.5. Я задался тем же вопросом применительно к Spring Boot: что происходит с уровнем защищённости приложения, когда используемая версия достигает End Of Life (EOL)?
Обычно жизненный цикл уязвимости представляют так:
Исследователь обнаруживает проблему.
О проблеме сообщают разработчикам проекта.
Уязвимости присваивают идентификатор CVE и оценку критичности.
Разработчики выпускают исправление.
Когда мы начинали строить продукт для распознавания и обработки первичных бухгалтерских документов — OCR, классификация, LLM‑извлечение полей, проверка человеком — казалось, что рынок оркестраторов уже всё решил: есть n8n для визуальных workflow, есть LangGraph для агентных пайплайнов, есть Temporal для durable‑исполнения. Мы попробовали примерить каждый — и в итоге написали свой: AgentsGraph, встраиваемую Java‑библиотеку декларативной оркестрации агентов. Ниже — почему.
Эта статья описывает архитектуру построения приложений на Java с помощью фреймворка Spring. Если вы используете другие языки программирования или фреймворки, возможно, вы также сможете найти соответствующие инструменты, подходящие именно вам.
Всем привет, меня зовут Михаил, я работаю Senior Java разработчиком в ОТП Банке.
Смотря на всю ситуацию на рынке, я подумал: хм, вот джуны притворяются мидлами и сеньорами и ходят по собесам. А что, если все будет наоборот?
Учитывая, что ситуация на рынке для джунов совсем плачевная, я решил провести эксперимент. 30 дней. Только я, фейковое резюме джуна, новый Telegram-аккаунт - и все!
В этой истории было все: отказы, тестовые, преофферы, даже один супер-гуру, который обещал научить меня всему - от тестирования до программирования ракет, лишь бы ему отдали деньги.
Привет! Это моя первая статья на Хабре, поэтому если будут какие‑то недочёты, не судите строго)
Не так давно я разрабатывал микросервисное приложение для анализа предпочтений пользователей на основе их книг. Оно должно было обрабатывать тысячи событий в день, чтобы рекомендовать пользователям новые произведения. И в один момент я столкнулся с классической болью распределенных систем: если брокер сообщений (например, Kafka) был временно недоступен, мои события терялись навсегда.
Однажды я решил проверить на практике байку, которую слышал на десятке собеседований: «у нас на проде было такое‑то место продано дважды, потому что…». Оказалось, воспроизвести это не просто легко — это воспроизводится настолько надёжно и настолько наглядно, что грех было не довести дело до конца: взять систему бронирования мест, специально сломать её, замерить, насколько плохо, а потом последовательно починить тремя разными способами — и честно сравнить, что каждый из них стоит по производительности.
Спойлер: один из результатов оказался прямо противоположным тому, что я ожидал увидеть.
Другого подходящего названия в голову не пришло, однако суть и принцип работы ПО, будет ясна всем.
Вообще, идея была — автоматизировать процесс проведения анализа и извлечения всей необходимой информации из вредоносного APK файла. Ряд программ уже существует в компьютерном мире, однако я понял для себя, что нет единого ящика, который бы мог держать в себе все необходимые инструменты и выполнять анализ более качественно и развернуто, ну и, соответственно, работать по цели.
