Clickbait. Treść filmu przeczy postawionej tezie.

@100x: ChatGPT zna odpowiedź ... :)
https://chat.openai.com/chat

@rafal-masny:

Serwlet

2. Nie autoryzować, mikroserwisy gadają ze sobą w zamkniętej sieci, utworzonej np. na poziomie dockera, dostęp z zewnątrz jest odcięty.

1. User z UI prawdopodobnie nie będzie uderzał do poszczególnych serwisów samodzielnie a bardziej przez API gateway, wtedy mając na API gateway listę endpointow możesz zapiąc autoryzację w jednym miejscu

@lukasj: dosc ciekawy wpis: https://netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602

Słyszałem o tokenach JWT - jednak odradzają je jako mechanizm takiej "sesji"

gdzie odradzają? zdecydowana wiekszosc obecnie stoi na jwt bym powiedzial

@GeDox:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

@Kamishimi:

List<Integer> result = Arrays.stream(testString.split(" ")).map(str -> str.replaceAll("\\D", "")).map(Integer::valueOf).collect(Collectors.toList());

@novak00: Cloud nie jest prawie do niczego potrzebny jeśli nie tykasz tematów devopsowych. Można być nawet seniorem, a w swojej karierze nie postawić ani jednego poda, co nie przeszkadza korzystać z nich jako "zwykły użytkownik" bez tajemnej wiedzy cloudowej.

@novak00: dajesz, ja mam seniora i też nic z tego nie umiem XD

@Pioneer95: jest cos takiego jak jhipster, moze tam zobacz jak generuja podstawowy projekt

@srgs: zobacz sobie ale nie używaj tylko zrób po swojemu... to jest dobre jak chcesz zrobić POC-a czegoś co i tak później napiszesz normalnie. Miałem okazję rozwijać aplikacje które ktoś rozpoczął w jhipsterze nie do końca go czając. Nie było opcji robić upgrade jhipstera(polityka w projekcie) a z drugiej strony sam jhister bardzo utrudniał on dalszy rozwój systemu.

@Patres: Problem z takimi prezentacjami jest taki, że są one "fajne" dlatego, że zawierają dużo hypowych tematów. Podczas, gdy tak naprawdę nie trzeba ich ze sobą mieszać, nikt tego nie sprawdza ( ͡° ͜ʖ ͡°).

Można używać DDD bez mikroserwisów, event sourcingu. CQRS można uznać za ortodoksyjne wdrożenie zasad SOLID, więc czasem wychodzi trochę samo. Architektura heksagonalna też trochę wyjdzie niemal sama po przestawieniu się na myślenie domenowe. SkupiamPokaż całość

@PoteznyMagWody @PaaD: Stosowanie DDD absolutnie nie wymaga programowania obiektowego. Wręcz przeciwnie: bardzo dobrze sprawdza się w wydaniu funkcyjnym, gdzie dąży się do wyraźnej separacji modelu od zachowania. Dostajecie wtedy encje/agregaty które są zdefiniowane zupełnie w oderwaniu od szczegółów implementacyjnych, co z kolei bardzo dobrze uzupełnia się z architekturą heksagonalną (o ile nie jest w ogóle jej dosłownym zaaplikowaniem).

@Patres Każdy z tych buzzwordów trzeba traktować jako narzędzie, którePokaż całość

@Patres: To jest w ogóle jakieś dziwne pytanie. O ile nie piszesz jakiegoś generic cruda to DTO nijak sie będą miały do obiektów domenowych, bo DTO są zdefiniowane przez dane które potrzebujesz gdzieś wysłać, podczas gdy obiekty domenowe są zdefiniowane przez logikę aplikacji.
W prawdziwym życiu nie pisze się aplikacji gdzie masz jakąś tabelkę za pomocą której modyfikujesz sobie wpisy w bazie danych ;) Takie bzdury to tylko w jakichśPokaż całość

@Patres: Takiego "prostego cruda" to nie ma sensu w ogóle pisać i rozważanie go do niczego nie prowadzi. W praktyce wcale nie będzie się różnić 1 polem bo połowa danych będzie dociągana z jakichś innych źródeł a nie z przychodzącego requestu (np. informacje o firmie z jakichś rejestrów) a potem do frontendu też nie będziesz wysyłać wszystkich danych firmy które masz w bazie.
Moja rada jest taka:

1. Budujesz domenę tak jakPokaż całość

@Patres: W warstwie serwisowej mapowanie z encji na dto, a w kontolerze mapowanie z dto na response/request

@Patres: Jeden rabin powie tak, a inny powie nie.
Ja generalnie preferuję mapowanie w kontrolerze albo dedykowanym mapperze, bo nie lubię jak serwis jest ściśle związany z jakimś widokiem. Jeśli będziesz chciał zrobić nową wersję endpointa z innymi DTO, to trudno wykorzystać istniejący serwis, jeśli przyjmuje on stare DTO jako input/output.

@kanarex: nie tworzysz tego obiektu, tylko pobierasz go z contextu aplikacji. Bierzesz context i przez niego pobierasz referencję do usługi systemowej 'wifi service'. Na koniec rzutujesz to na typ WifiManager.

@nobodyelse: a to nie lepiej od razu na staż iść do nich?

@nobodyelse nie idź tam

@kanarex: taguj #androiddev

@Pan_Tomek: Coś się u Was dzieje na projekcie? Może masz jakieś tickety do rozwiązania? ( ͡° ͜ʖ ͡°) Chętnie coś pokodzę pożytecznego

@ly000: ten argument jest w ogóle bez sensu bo Java ma pointery. A NullPointerException to co, pies?

@HeavyMagicMissle: Jak rozpoznać juniora? Nie trzeba, sam ci powie że jego język jest lepszy niż x.

raczej A choć to zależy. Użyłbym B jeśli element zmienny jest prosty do ogarnięcia. Dobrym przykładem mogłoby być image.ExportAs(ImageType.PNG) zamiast image.ExportAsPNG(): co prawda logika konwersji z generycznego obrazka do PNG jest pewnie cholernie skomplikowana to koncepcyjnie jest to proste do ogarnięcia: wynikiem ma być ten sam obrazek tylko w formacie PNG co łatwo zweryfikować

W twoim wypadku pewnie wolałbym A jeśli jest tam inna logika a B, jeśli nie np. elementPokaż całość

@aczutuse: to powiem stare porzekadło - rób jak uważasz i uważaj jak robisz :>
A tak imho to nie ma co się zbytnio spuszczać - ważne żeby działało i przynosiło wartośc biznesową.