в добавок к этой статье можно сказать, что на практике Entity сущности могут работать с enum перечислениями и это удобно.
Но!
Когда enum является полем сущности, но значения хранимые в БД отличаются от имен enum перечислений, то тогда нужен обработчик маппинга для сопоставления между значением приходящим из БД и enum перечислением в Java проекте. Вот удалось описать одно из решений из моего проекта - https://habr.com/en/articles/747140/
Да поддержу. block методы в Spring Reactor вообще рискованно использовать. Сам на практике напоролся один раз на deadlock и оформил статьей на память - https://habr.com/en/articles/741464/
Антон, поддерживаю. Хорошая статья. Тоже написал пост на то как выглядит работа по Agile изнутри глазами разработчика - https://habr.com/en/articles/743970/ К сожалению, у меня как у технического специалиста нету положительного опыта от аджайла.
but from my perspective by capital letters better:
Closer to convention. It states that should be one letter + digits. Here I suggest by capitals. For example if class name contain 3 words - will be 3 letters. It exactly defines the class is such case.
Class name could be really long - how will you name type parameter in this case? It will match to class name? Long parameter names - not usual practice.
Class name could differ only by 1 word from 3. For example - FlowParamBuilder and TaskParamBuilder. How you suggest to name type parameter in this case? I think that FPB and TPB will fit good here. If needed - even in IDEA you can find the class by type parameter capitals.
Hello, had a look at the article. I cannot comment there, because article in sandbox. Will write here - not bad, but there should be some common rules in development for your topic. For example rule #1 - don't do black window and so on.
Sergey, hello!
Big and interesting article.
I think that in future time articles in English will be more and more popular on Habr.
And what is interesting - is that it might be read in other countries.
в добавок к этой статье можно сказать, что на практике Entity сущности могут работать с enum перечислениями и это удобно.
Но!
Когда enum является полем сущности, но значения хранимые в БД отличаются от имен enum перечислений, то тогда нужен обработчик маппинга для сопоставления между значением приходящим из БД и enum перечислением в Java проекте. Вот удалось описать одно из решений из моего проекта - https://habr.com/en/articles/747140/
Да поддержу. block методы в Spring Reactor вообще рискованно использовать. Сам на практике напоролся один раз на deadlock и оформил статьей на память - https://habr.com/en/articles/741464/
Антон, поддерживаю.
Хорошая статья.
Тоже написал пост на то как выглядит работа по Agile изнутри глазами разработчика - https://habr.com/en/articles/743970/
К сожалению, у меня как у технического специалиста нету положительного опыта от аджайла.
It is up to you, if you like can give long names.
but from my perspective by capital letters better:
Closer to convention. It states that should be one letter + digits. Here I suggest by capitals. For example if class name contain 3 words - will be 3 letters. It exactly defines the class is such case.
Class name could be really long - how will you name type parameter in this case? It will match to class name? Long parameter names - not usual practice.
Class name could differ only by 1 word from 3. For example - FlowParamBuilder and TaskParamBuilder. How you suggest to name type parameter in this case? I think that FPB and TPB will fit good here. If needed - even in IDEA you can find the class by type parameter capitals.
Hello, had a look at the article. I cannot comment there, because article in sandbox. Will write here - not bad, but there should be some common rules in development for your topic. For example rule #1 - don't do black window and so on.