Инженер-программист
Сегодняшняя задача вполне традиционна для любых учетных систем - поиск записей, содержащих максимальное значение по каждому из ключей. Что-то вроде "покажи мне последний заказ по каждому из клиентов", если переводить в прикладную область.
Кажется, что тут и споткнуться-то негде в реализации - но все оказывается совсем не тривиально.
На данный момент на рынке мало Event sourcing + CQRS фреймворков. А те, что есть, непопулярны и имеют слабую поддержку, поэтому многие создают свои in-house решения. В этой статье расскажу о выполненном командой «Programming Store» проекте Prostore, который может послужить примером при создании вашего собственного решения.
По мере роста вашей инфраструктуры наличие роботов и надежная централизованная система логирования становится критически важными составляющими. Централизация логирования становится ключевым аспектом множества IT-задач и дает вам хороший обзор всей вашей системы.
Лучшее решение — агрегировать логи с метаданными из всех контейнеров. Это предоставит вам лучшие варианты отслеживания и возможность получить хорошую поддержку от сообщества. Здесь на сцену выходит ELK Stack. ELK, также известный как Elastic stack, представляет собой комбинацию современных инструментов с открытым исходным кодом, таких как ElasticSearch, Logstash и Kibana. Это полное решение для сквозного анализа журналов, которое вы можете использовать в своей системе.
Каждому компоненту отведена определенная роль: ElasticSearch лучше всего хранит необработанные логи, Logstash помогает собирать и преобразовывать логи в согласованный формат, а Kibana добавляет отличный уровень визуализации и помогает вам управлять вашей системой в удобной для пользователя манере.
В этом руководстве вы узнаете, как развернуть ELK и наладить агрегирование контейнерных логов. Мы собираемся объединить ELK с Filebeat, чтобы агрегировать контейнерные логи. Для этого мы собираемся создать собственный образ Docker.
Spring Security — must-have компонент в Spring-приложениях, так как он отвечает за аутентификацию пользователя, а также за авторизацию тех или иных его действий в системе. Одним из методов авторизации в Spring Security является использование аннотации @PreAuthorize, в которой с помощью выражений можно наглядно описать правила, следуя которым модуль авторизации решает, разрешить ли проведение операции или запретить.
В моём REST-сервисе возникла необходимость предоставить точку доступа к описанию правил авторизации для всех методов контроллеров сервиса. Причём, по возможности, избежать раскрытия специфики именно SpEL-выражений (т.е., вместо permitAll нужно что-то вроде anybody, а principal избегать вовсе как избыточное выражение), но возвращать свои выражения, с которыми уже можно делать что угодно.
При работе с большой кодовой базой довольно естественно не помнить каждую подсистему или вариант реализации. Особенно если вы новичок в кодовой базе, или вы сосредоточились на определенной области кодовой базы.
Большинство людей начнут с использования «git blame» (или соответствующей функциональности в своей среде IDE/редакторе). Но в большинстве нетривиальных проектов вы обычно заканчиваете коммитом рефакторинга, переименованием или тривиальным исправлением проекта, например переключением на другую библиотеку assertion. При первом взгляде, мы видим только самые последние изменения, но не самые важные.
Нам нужно аккуратно удалить слой за слоем песок и грязь, которые были нанесены на реальные изменения, чтобы выявить их.
Представьте довольно распространённую ситуацию: ваше приложение взаимодействует с клиентами, которые находятся в разных часовых поясах. Вам часто приходится работать с датами, а для корректной работы системы, они передаются с указанием часового пояса отправителя. При этом, вам нужно:
1) При получении запроса привести дату к серверному времени и сохранить в базу данных в таком виде
2) В ответ возвращать дату и время с указанием серверного часового пояса
Чтобы избавиться от лишних вызовов методов для преобразования даты, Spring предоставляет удобный механизм для написания кастомной сериализации и десериализации.
Вторая статья из цикла "Test-Driven Development приложений на Spring Boot" и в этот раз я буду говорить про тестирование доступа к базе данных, важного аспекта интеграционного тестирования. Я расскажу как через тесты определять интерфейс будущего сервиса для доступа к данным, как использовать встраиваемые in-memory базы для тестирования, работать с транзакциями и загружать тестовые данные в базу.
Spring Framework часто приводят как пример Cloud Native фреймворка, созданного для работы в облаке, разработки Twelve-Factor приложений, микросервисов, и одного из самых стабильных, но в то же время инновационных продуктов. Но в этой статье я бы хотел остановиться на еще одной сильной стороне Spring: это его поддержка разработки через тестирование (TDD-руемость?). Не смотря на TDD-руемость, я часто замечал, что в проектах на Spring либо игнорируются некоторые best practices для тестирования, либо изобретаются свои велосипеды, либо вообще не пишутся тесты потому что они "медленные" или "ненадежные". И вот именно о том, как писать быстрые и надежные тесты для приложений на Spring Framework и вести разработку через тестирование я и расскажу. Так что если вы используете Spring (или хотите начать), понимаете что такое вообще тесты (или хотите понять), или думаете что contextLoads это и есть необходимый и достаточный уровень интеграционного тестирования — то будет интересно!
В статье представлен пример локального окружения, построенного с использованием технологий: Docker Compose, Consul, Make — для разработки Spring Boot веб-сервисов.
Демонстрационное приложение будет по ссылке на страницу возвращать ссылку на наибольшее по размеру изображение с указанной страницы. Изображения будут извлекаться через Browserless, а PostgreSQL будет хранилищем результатов.
В большинстве моих собеседований на технические позиции есть задача, в которой кандидату необходимо реализовать 2 очень похожих интерфейса в одном классе:
Реализуйте оба интерфейса одним классом, если это возможно. Объясните, почему это возможно или нет.
interface WithPrimitiveInt {
void m(int i);
}
interface WithInteger {
void m(Integer i);
}От переводчика: Эта статья не призывает вас задавать такие же вопросы на интервью. Но если вы хотите быть во всеоружии, когда этот вопрос зададут вам, то добро пожаловать под кат.
