create or replace package - если влоб миграциями - неудобно дифы смотреть

Можно использовать повторяющиеся миграции, которые наказываются каждый раз всегда и в них править пакеты

Можно использовать повторяющиеся миграции, которые наказываются каждый раз всегда и в них править пакеты

Repeatable вроде только в платном flyway

Repeatable вроде только в платном flyway

Нет

Зачем?

Зачем?

Люблю градл

Люблю градл

градл > говно > моча > мавен > ант + иви > башскрипты?

градл > говно > моча > мавен > ант + иви > башскрипты?

sbt?

градл > говно > моча > мавен > ант + иви > башскрипты?

Градл дерьмовее дерьма?

Непонятные слова(

Какое там кстати будущее у maven? Мне он очень нравится (:

Какое там кстати будущее у maven? Мне он очень нравится (:

https://blog.ltgt.net/maven-is-broken-by-design/

Вот держи, сам посуди

Можешь в принципе только урл прочитать, саму статью не обязательно

Какое там кстати будущее у maven? Мне он очень нравится (:

Никуда он не денется

Repeatable вроде только в платном flyway

Oracle только в платном

Никуда он не денется

Не. Это понятно. Меня интересует что-то типа maven 4 (: он же когда-нибудь апнется.

Нет

Точно, undo в платном

Не. Это понятно. Меня интересует что-то типа maven 4 (: он же когда-нибудь апнется.

На Хабре было интервью с разработчиком недавно. Судя по всему будет когда нибудь и 4я версия и 5я

На Хабре было интервью с разработчиком недавно. Судя по всему будет когда нибудь и 4я версия и 5я

Есть идеи для 4й и 5й версий и они будут - разные вещи ?

Есть идеи для 4й и 5й версий и они будут - разные вещи ?

Ну, есть идеи - дело за малым :))

Конец мавена пророчили уже кучу лет назад, как только гредл в массы пошёл. Но нет, как был процентов 70% от рынка так наверное и есть

А можно до того как Мавен, хотя бы Ант сдохнет?

ребята, хочу использовать oauth2 для security rest api, которое будут использовать другие приложения + public UI. какой grant type надо использовать для случая с UI? по идее там у меня будет только логин/пароль, но не будет client_secret

А можно до того как Мавен, хотя бы Ант сдохнет?

пусть оба усопнут, а вот мейкфайлы хай живе

разве есть что-то лучше гредла?

bash

разве есть что-то лучше гредла?

sbt :trollface:

bash

Automake не здесь

вон Антона спроси, он эксперт по сбт?

Automake не здесь

Ниасилил autotools

Ниасилил autotools

да, я ниосилятор gcc

Не вижу проблемы в gcc (: В autotools вижу, в gcc нет.

Че там его осиливать то. Один раз make файл руками написал и все становится "понятно".

мейк файлы я осилил, они-то простые

а в gcc и автомейке столько нюансов

m4 помню ещё ужасный но это рядом

gradle на make похож целями

Мне больше cmake симпатичен (:

а что, в sbt тоже есть цели и зависимости?

и умеет ли sbt из мавенов вытаскивать?

а что, в sbt тоже есть цели и зависимости?

ну что-то называемое этими словами есть, не уверен, что хочешь-то

и умеет ли sbt из мавенов вытаскивать?

вызывать что?

sbt?

Он же тормозной

Скалисты интесифайс после этой фразы

http://www.lihaoyi.com/post/SowhatswrongwithSBT.html

Я думаю про любой билд тул можно такое написать

Ну мужик свой билд тул потом написал

Ну мужик свой билд тул потом написал

Ну ещё бы.. популярный? :)

Он же тормозной

ЧТО

Ну мужик свой билд тул потом написал

*пишет

https://github.com/lihaoyi/mill

а вообще билд-тулы — штука неблагодарная я ни одного не знаю, в который не кидаются какашками

больно много там сложностей

Поэтому, keep calm and use maven

На каждый билд тул найдутся любители :)

Он же тормозной

он не только тормозной, он еще и не фига не simple - тот же мавен куда интуитивнее же

он не только тормозной, он еще и не фига не simple - тот же мавен куда интуитивнее же

мавен чутка другой идеологически

и там и там у меня работа сводилась к гуглежу готового решения, а когда (редко!) приходилось писать свой плагин или что-то такое, всегда ругался и курил доку

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

ну и sbt давно не simple расшифровывается

ребята, хочу использовать oauth2 для security rest api, которое будут использовать другие приложения + public UI. какой grant type надо использовать для случая с UI? по идее там у меня будет только логин/пароль, но не будет client_secret

password

password

При это client_secret необязательный?

ERROR: S client not available

При это client_secret необязательный?

Да, можно указывать только client_id.

Да, можно указывать только client_id.

Но некоторые имплементации считают client_secret обязательным, со swagger UI у меня были проблемы, например. Проще, когда client_secret все-таки есть.

ребят, кто-то может подсказать, есть ли возможность у spring security аннотировать методы rest-контроллера чем-то типа @RequireAuth, например, требуя доступ к методу через какой-то токен?

ну то есть типа что бы можно было сделать так: @GetMapping("/hello") @RequireAuth(Permissions.ADMIN) public String hello() { ... }

ребят, кто-то может подсказать, есть ли возможность у spring security аннотировать методы rest-контроллера чем-то типа @RequireAuth, например, требуя доступ к методу через какой-то токен?

Это аннотации @PreAuthorize и @PostAuthorize

Это аннотации @PreAuthorize и @PostAuthorize

окей, спасибо, полетел гуглить

Гайз, а сваггером со спрингом же почти каждый пользуется, да? Кто что делает с мапами? Их вообще лучше не использовать? Или норм тема в дто?

Просто в сваггере выглядят они криво ужасно

А что с ними?

Ща фоткну

вот это смущает

Это намек

Это намек

Я в намёках не силён )

Кто-то может помочь в вопросе?

В банковском приложении есть метод (транзакция), который служит для перевода денег с одного аккаунта на другой, например: void transfer(Account acc1, Account acc2, int money). Как реализовать эту транзацию правильно в многопоточной среде? Например, поставить synchronized для метода transfer - неправильно, потому что в таком случае все аккаунты, ожидающие на трансфер будут на блокировке, пока не выполнится текущий transfer

В банковском приложении есть метод (транзакция), который служит для перевода денег с одного аккаунта на другой, например: void transfer(Account acc1, Account acc2, int money). Как реализовать эту транзацию правильно в многопоточной среде? Например, поставить synchronized для метода transfer - неправильно, потому что в таком случае все аккаунты, ожидающие на трансфер будут на блокировке, пока не выполнится текущий transfer

Сделать тонкую блокировку

как?

На каждый аккаунт сделать свой лок

В банковском приложении есть метод (транзакция), который служит для перевода денег с одного аккаунта на другой, например: void transfer(Account acc1, Account acc2, int money). Как реализовать эту транзацию правильно в многопоточной среде? Например, поставить synchronized для метода transfer - неправильно, потому что в таком случае все аккаунты, ожидающие на трансфер будут на блокировке, пока не выполнится текущий transfer

Звучит как задача на собеседовании

как синхронизировать одновременно 2 аккаунта?

И блокировать только account1.lock() и account2.lock()

надо это сделать одновременно...

Кроме того, блокировка должна быть иерархической

В банковском приложении есть метод (транзакция), который служит для перевода денег с одного аккаунта на другой, например: void transfer(Account acc1, Account acc2, int money). Как реализовать эту транзацию правильно в многопоточной среде? Например, поставить synchronized для метода transfer - неправильно, потому что в таком случае все аккаунты, ожидающие на трансфер будут на блокировке, пока не выполнится текущий transfer

в Java Concurrency In Practice есть такой пример

То есть должен быть полный порядок захвата

Читай про fine-grained и two-phase locking

В банковском приложении есть метод (транзакция), который служит для перевода денег с одного аккаунта на другой, например: void transfer(Account acc1, Account acc2, int money). Как реализовать эту транзацию правильно в многопоточной среде? Например, поставить synchronized для метода transfer - неправильно, потому что в таком случае все аккаунты, ожидающие на трансфер будут на блокировке, пока не выполнится текущий transfer

лок на запись в базу

работает более чем отлично

работает более чем отлично

и не разваливается при нескольких инстансах приложения

и не разваливается при нескольких инстансах приложения

+