и спринг обертка

где все тот же фейн, но с аннотациями спринга

спасибо, буду разбираться

у нас RestEasy - полёт нормальный

у нас RestEasy - полёт нормальный

ага, тоже гляну, спасибо

ну т.е. из современного опции только 2 - Feign Client и Spring?

А Retrofit?

у мне не андройд

у мне не андройд

А он и без ведра работает

а смысл, если в проекте реактивщины нет?

привет, на каких библиотеках сейчас модно писать клиенты к rest-интерфейсу на Java?

https://swagger.io/ удобный генератор есть. Не без глюков, но вполне рабочее решение

https://swagger.io/ удобный генератор есть. Не без глюков, но вполне рабочее решение

даже приятная штука, плюс вроде саппортят и развивают. единственная проблема была с операцией, в рамках которой делали multiple file upload. хотя можт пофиксали)

https://swagger.io/ удобный генератор есть. Не без глюков, но вполне рабочее решение

кстати, а он интерфейс фейн клиента по рест апи может сгенерировать?

даже приятная штука, плюс вроде саппортят и развивают. единственная проблема была с операцией, в рамках которой делали multiple file upload. хотя можт пофиксали)

а ещё pageable спринговый не умеет распознавать и java.time из java 8

а ещё pageable спринговый не умеет распознавать и java.time из java 8

про pageable не знаю, про java8 date нашёлся PR: https://github.com/swagger-api/swagger-codegen/pull/1784 - вроде можно выбирать либу для работы с датами)

день добрый, кто-нибудь с aws sdk и cloudwatch events работал? я создал с помощью sdk два правила с выполением по крону, оба фейлятся при выполнении, открыл редактирование одного в вебе, ничего не меняя сохранил, теперь одно правило работает, второе - нет, выглядят идентично.Никакой внятной документации что такое FailedInvocations не видно, логов тоже не видно, грусть и печаль..

@VAlekseev

что такое?

Сообщение выше чекни, ты ж у нас авс мастер

не работал с этим

не знаю, одно дело звезды на гитхабе, другое промышленные стандарты разработки

Feign нужен для сервисов в облаке, т.е. когда у тебя не один инстанс какого-нибудь api, он еще и в балансировку умеет

понятно, спасибо облако уже написано, теперь надо клиенты под все популярные платформы сделать ?

понятно, спасибо облако уже написано, теперь надо клиенты под все популярные платформы сделать ?

Если ты снаружи облака вызываешь сервисы через скажем api gateway какой-нибудь, то можешь любой http клиент юзать, взять тот же okhttp

Если нужно взаимодействие внутри облака между сервисами то Feign

сейчас задача сделать cli и библиотеки для пользователей rest-интерфейса и передавать данные через json

потом будет задача сделать то же самое, но вместо json использывать кастомный протокол

из текущих предложение самым адекватным пока выглядит Jersey

А есть кто-нибудь кто ходил в Яндекс в СПб на собеседование недавно на мидла-синьора?) Напишите в лс плз

есть кто из jetbrains и может рассказать что в их багтрекере значит triaged и какие у него статусы есть?

тут был адвокат

тут был адвокат

ты наверное хотел сказать - @fundamentalparticle :)

да)

есть кто из jetbrains и может рассказать что в их багтрекере значит triaged и какие у него статусы есть?

Переводчик/словарь ни о чем не напомниает? ? Это поле про первичную обработку тикетов. AFAIK Triaged == Yes значит что кто-то из команды посмотрел на ишую и расставил правильные поля, убедился что тикет валидный

а есть кто уже девятку прям под спринг бутом и прочими вещами пользовал?

Тебе в проде или дома под одеялом ?

а то я слегка разочарован тем, что запустил на девятке и получил... java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader

пока на локальной машине

спринг буть

Ну я пятый спринг с флаксом завел

Нормально все поехало

а то я слегка разочарован тем, что запустил на девятке и получил... java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-with-Java-9

оо.. покопаю

там вроде прямым текстом сказано, что надо spring boot 2

хорошо

я просто попробовал

заводили на альфе бута второго

работает

даже с ломбоком

скоро rc будет

есть кто из jetbrains и может рассказать что в их багтрекере значит triaged и какие у него статусы есть?

triaged - это значит на него посмотрели

видел в одном тестовом задании. даже сделал ради интереса, но в однострочник - не осилил

Типа это можно сделать одной строкой?

Типа это можно сделать одной строкой?

Хз, я ж говорю, не осилил. Я правда в стримы и лямбы не особо умею, делал как раз для практики

Типа это можно сделать одной строкой?

на rxJava делается без проблем в одну строку

А на скале ? )

а на скале rxJava работать не будет?

есть rxscala

ERROR: S client not available

сори случайно

А на скале ? )

Выше был пример на скалке

в телеграмме можно удалять свои сообщения

Парни всем привет

Вопросы про спринг можно тут?

да тут про все)

про спринг вроде есть чат еще

про спринг вроде есть чат еще

кинь ссылку плз

про спринг вроде есть чат еще

Не рекомендую его никому

Не рекомендую его никому

это тот, который тот?)

Там поехавшие новички свитчеры после курсов

это тот, который тот?)

Видимо

сори, буду знать)

В канале про Кафку добавил текст про популярный вопрос - иметь один топик для всех сообщений или много топиков под один тип сообщений

Всем привет. Рубрика «По Вашим письмам» Столкнулся с жутким бадхертом от подхода работы с кафкой в котором используют лишь одну очередь для хранения всех сущностей! До этого столкновения не небольшом проекте использовалась кафка для хранения в отношении "очередь-сущность" - концептуального отличия от типичного SQL подхода(типичного ибо Event Driven только врываеться в широкие массы насколько я могу судить по своему кругу общения) только в том что данные в памяти всегда, в виде последние версии обьектов. будто очередь это таблица. Но тут появился этот концепт одной очереди с аргументом - гарантировать порядок прихода сообщений(так как тз подразумевало достаточно сильную разбросанность по миру конечной системы). И я понимаю что теоретически и технически это возможно(в конце концов есть конечное время прохождения сигнала даже на физическом уровне, и в масштабах планеты это может сказаться). Но вот кейсы когда конечный пользователь будет создавать сущности в неверном порядке мне не совсем приходят на ум. или такое «А какие есть best practices на тему хранения сообщений разного типа в одном Kafka топике? Например, чтобы все сообщения класть в одно место, а уже Consumer сам разберется. Или наоборот, деть fine-grained топики - под определенный тип сообщения. И как вы понимаете, ответ на этот вопрос - it depends (duh). Давайте подумаем, от чего это может depends: - Если порядок сообщений важен, сообщения должный попадать в один топик. Важно помнить - Kafka гарантирует порядок только на уровне partition. Для этого необходимо указывать правильный ключ (например, если важен порядок банковских транзакций ID аккаунта может использоваться в качестве ключа). Или иметь топик с 1 partition. - Сообщения разного типа, но связанные бизнес-логикой (как в предыдущем примере, сообщения могут быть разного типа - CreditEvent, DebitEvent, etc) - Еще такой момент - не надо бояться использовать Kafka для хранения RAW сообщений - порезать, отфильтровать и разделить их можно всегда, а объединять может оказаться не всегда просто / нужно. Вычитывание сообщений достаточно «легкая» операция, но тут надо иметь меру - не имеет смысла сидеть и слушать сообщения, 90% из которых придется выбросить. - еще интересный момент с Kafka Streams. API заточен на семантику «один топик - один тип сообщений, что может затруднить использование этого фреймворка в ситуации, когда в топике присутствуют сообщения разного типа. Кстати, этим вопросом так же озадачился Мартин Клеппманн и накатал добрую портянку текста. Полную версию (eng) можно прочитать тут https://www.confluent.io/blog/put-several-event-types-kafka-topic/ Там, кстати, так же затрагивается вопрос «A как же быть со схемами?» Он даже запилил PR https://github.com/confluentinc/schema-registry/pull/680 для Confluent Schema Registry, который, если вы используете Avro Serializer позволяет работать с разными типа сообщений более проще.

Всем привет. Рубрика «По Вашим письмам» Столкнулся с жутким бадхертом от подхода работы с кафкой в котором используют лишь одну очередь для хранения всех сущностей! До этого столкновения не небольшом проекте использовалась кафка для хранения в отношении "очередь-сущность" - концептуального отличия от типичного SQL подхода(типичного ибо Event Driven только врываеться в широкие массы насколько я могу судить по своему кругу общения) только в том что данные в памяти всегда, в виде последние версии обьектов. будто очередь это таблица. Но тут появился этот концепт одной очереди с аргументом - гарантировать порядок прихода сообщений(так как тз подразумевало достаточно сильную разбросанность по миру конечной системы). И я понимаю что теоретически и технически это возможно(в конце концов есть конечное время прохождения сигнала даже на физическом уровне, и в масштабах планеты это может сказаться). Но вот кейсы когда конечный пользователь будет создавать сущности в неверном порядке мне не совсем приходят на ум. или такое «А какие есть best practices на тему хранения сообщений разного типа в одном Kafka топике? Например, чтобы все сообщения класть в одно место, а уже Consumer сам разберется. Или наоборот, деть fine-grained топики - под определенный тип сообщения. И как вы понимаете, ответ на этот вопрос - it depends (duh). Давайте подумаем, от чего это может depends: - Если порядок сообщений важен, сообщения должный попадать в один топик. Важно помнить - Kafka гарантирует порядок только на уровне partition. Для этого необходимо указывать правильный ключ (например, если важен порядок банковских транзакций ID аккаунта может использоваться в качестве ключа). Или иметь топик с 1 partition. - Сообщения разного типа, но связанные бизнес-логикой (как в предыдущем примере, сообщения могут быть разного типа - CreditEvent, DebitEvent, etc) - Еще такой момент - не надо бояться использовать Kafka для хранения RAW сообщений - порезать, отфильтровать и разделить их можно всегда, а объединять может оказаться не всегда просто / нужно. Вычитывание сообщений достаточно «легкая» операция, но тут надо иметь меру - не имеет смысла сидеть и слушать сообщения, 90% из которых придется выбросить. - еще интересный момент с Kafka Streams. API заточен на семантику «один топик - один тип сообщений, что может затруднить использование этого фреймворка в ситуации, когда в топике присутствуют сообщения разного типа. Кстати, этим вопросом так же озадачился Мартин Клеппманн и накатал добрую портянку текста. Полную версию (eng) можно прочитать тут https://www.confluent.io/blog/put-several-event-types-kafka-topic/ Там, кстати, так же затрагивается вопрос «A как же быть со схемами?» Он даже запилил PR https://github.com/confluentinc/schema-registry/pull/680 для Confluent Schema Registry, который, если вы используете Avro Serializer позволяет работать с разными типа сообщений более проще.

годнота, вот такое бы в РП обсуждать

годнота, вот такое бы в РП обсуждать

Да там хейтеры Кафки в лице @jbaruch

Да там хейтеры Кафки в лице @jbaruch

не, ну зачем, можно сделать РП:Кафка, для упоротых, и удачи.

продавать франшизу

готов поспорить, что хардкорный выпуск про кафку наберет куда больше слушателей, чем про опостылевший артефактори

готов поспорить, что хардкорный выпуск про кафку наберет куда больше слушателей, чем про опостылевший артефактори

а когда был выпуск про Артифактори?

надо послушать

а когда был выпуск про Артифактори?

да ты в каждом вклиниваешься, когда есть возможность

да ты в каждом вклиниваешься, когда есть возможность

примеры, или напиздел

примеры, или напиздел

первое, что вспомнил -- выпуск про докер и гарантированно одинаковую сборку контейнера

или это в радиоте было

первое, что вспомнил -- выпуск про докер и гарантированно одинаковую сборку контейнера

да, говорить о docker registry в выпуске о докере - это же как я вообще посмел, сука.

да, говорить о docker registry в выпуске о докере - это же как я вообще посмел, сука.

ужс, да а про кафку-то ничего нет!