@Kundzio1500: Trochę się spóźniłem, ale czy to nadal aktualne? :P

@SuppressWarnings: @ponton: Programowanie obiektowe to nie jest SQL.

@foobarek: Nie do końca rozumiem Twój problem. Wygląda mi jakbyś miał wszystko czego potrzebujesz - Szkolenie ma pole listaObecności (powinno być List). Wtedy jeśli chcesz oznaczyć, że pracownik był na szkoleniu to po prostu dodajesz go do tej listy.
Jaki dokładnie problem chcesz rozwiązać?

@fortySeven: Ja mam HyperX Cloud 2 ( https://tinyurl.com/yc636yqb ). Odizolowują od świata perfekcyjnie. Moja żona ich nienawidzi. Pozdrawiam.

edit: A sory, nie mają aktywnego wyciszania, ale i tak ładnie tłumią.

@Emil1803: Spoko main bus, tylko musisz zostawiać o wiele więcej miejsca na produkcję stuffu. Main bus ma tę wadę, że podstawowych materiałów schodzą tony więc musisz dbać o dobre zasilanie płytkami i zielonymi circuitami.
Dodatkowo - rzeczy takie jak koła zębate i drut miedziany lepiej wytwarzać bezpośrednio w miejscu gdzie ich potrzebujesz, niż ciągnąć po main busie.

BTW: ja jestem wielkim fanem fabryk spaghetti. Nie lubie main busów :<

@Emil1803: Jak zastanawiam się czy coś powinno iść na main bus to biorę pod uwagę dwa czynniki:
1) czy można to szybko wyprodukować na miejscu (np. miedziane druty, koła zębate)
2) czy to jest coś z czego korzysta wiele innych przepisów (green circuit, red circuit)

Bo np. nie ma dużej potrzeby robienia 12 pasów z kołami zębatymi jak wystarczą często 1 - 2 fabryki na miejscu . Tak samo niePokaż całość

@goorskypl: Mnie kolega namawiał chyba z 2 lata żebym pograł, a ja się opierałem. Niedawno kupiłem bo było dość tanio. Dzisiaj mam 600h, a moja żona nienawidzi tej gry.

Polecam.

Ja ostatnio używam czegoś takiego: https://bit.ly/2G5Trdp Teraz kombinuję jak to podłączyć do OpenHABa bez flashowania customowego firmware (Tasmota).

@noarch masz na myśli serwisy jak w mikroserwisach czy serwisy jak w klasy serwisowe w jednej aplikacji?
Kojarzysz co to warstwowa struktura aplikacji?

@noarch: W takim razie sprawa jest dość prosta. W każdym z serwisów powinieneś oddzielić model domenowy danego serwisu od modelu komunikacyjnego (np. danych zwracanych na endpointach, lub w klientach do innych usług). Potem trzeba tylko napisać kawałek kodu do konwertowania jednego modelu na drugi.

Niestety jest to sporo pisania ale daje Ci dużą swobodę w modyfikacji każdego modelu osobno bo konwerter zawera informację co tłumaczysz na co i jest jedynymPokaż całość

@noarch: Jeśli jeden pakiet potrzebuje danych prywatnych drugiego pakietu to może być to jedna z takich sytuacji:
1) Prywatne dane drugiego pakietu nie są tak na prawdę prywatne i trzeba je wstawić na jakimś interfejsie komunikacyjnym
2) Coś jest nie tak z odpowiedzialnościami i/lub rzeczy są zbyt mocno podzielone. Wtedy trzeba się dobrze zastanowić nad tym co się tak na prawdę dzieje.

Dodam tylko, że ogólnie te wszystkie zasady odnośnie układania kodu, wszelkiePokaż całość

@noarch: Mam wrażenie, że to o czym piszesz w pkt. 2 to jest dokładnie to co opisałem. Trudno mi tak na prawdę doradzić coś sensownego, bo widzę, że masz jakiś konkretny problem w konkretnym projekcie i bez zobaczenia jak to jest i co właściwie stanowi problem chyba nie pomogę bardziej.

@CiekawskiJ zwracaj konkretne obiekty. Nie widziałem jeszcze przypadku, który wymagałby zwracania ResponseEntity

@CiekawskiJ Endpointy u mnie zwracają Obiekty DTO Z @ResponseBody. Kod zwracany można określić przez @StatusCode a customer headery można CHYBA ustawiać na HttpServletResponse, które sobie zainjectujesz do metody endpointu.

@CiekawskiJ no chodziło o @ResponseStatus :)
Dlaczego miałbyś chcieć zwracać inny status niż zadeklarowany na endpoincie?
Z jakich lat były te artykuły z dobrymi praktykami? Nie mówię że jest ona zła. Po prostu uważam, że używanie @RsponseBody jest lepsze :)

Mamy sytuację, że wywołanie danego endpointu powinno zakończyć się Http 200, ale dany request może zajmować różny czas i dla dłuższego przetwarzania requestów chcielibyśmy zwrócić klientowi Http 202, w metodzie z adnotacją @ResponseStatus byłoby to niemożliwe

W moim rozumowaniu to właśnie @ResponseStatus uratuje Twoje API przed pochopnymi decyzjami ;)

Dany endpoint powinien działać w jeden konkretny sposób. Klient musi wiedzieć czy dostanie odpowiedź, czy musi później o zapytać o status żądania. TakiPokaż całość