Quiz na Instagramie już rozwiązałeś? 😃

@@JakNauczycSieProgramowania Oczywiście, fajne pytania nawiązujące do filmu😀. Czekam na więcej, bo mi się podobało :D.

Kejeszan Kejeszan Dzięki, cieszę się, że się podoba!

To z 401 i 403 jest zaskakujące i bardzo nieoczywiste :)

Ogólnie planuję, ale raczej nie w najbliższym czasie :) Z tych, które wymieniłeś na pierwszy ogień pójdzie chyba RabbitMQ, ale to też dopiero za jakiś czas.

Thymeleafem interesować się nie ma sensu, to martwa technologia :) Generalnie jeżeli chodzi o frontend to w zasadzie odeszło się już od jakichkolwiek javowych rozwiązań, standardem są technologie javascriptowe, przede wszystkim w postaci takiej złotej trójki React, Angular, Vue. Niedawno pojawił się jeszcze jeden ciekawy gracz w postaci Svelte i nim też warto się zainteresować.

Nie wiem jeszcze kiedy, ale będzie :)

@@JakNauczycSieProgramowania Super. Pozdrowienia z TT:)

Siema! Tak, studiowałem na Politechnice Łódzkiej. Inżynierkę robiłem na IFE, magisterkę zaocznie na FTIMS. Zaczynając od inżynierki, kończyłem Telecommunications & Computer Science czyli angielski odpowiednik kierunku Elektronika i telekomunikacja z Wydziału Elektrycznego. Pod kątem nauki programowania na IFE lepszy będzie jednak kierunek Information Technology czyli odpowiednik informatyki z FTIMS-u. Samo IFE wspominam bardzo dobrze - bardzo wysoki poziom nauki, bardzo ogarnięci ludzie, a do tego lepsze niż na polskich wydziałach, bardziej profesjonalne podejście do studenta. Dużym atutem jest również obowiązkowy wyjazd na pół roku lub rok na wymianę na Erasmusa, gdzie oczywiście można się dobrze bawić, ale przy okazji można się też dużo nauczyć. Ja byłem przez rok w Kopenhadze i pomimo dużo mniejszej ilości zajęć niż w Polsce - w Polsce miewałem semestry, w których w tygodniu spędzałam na uczelni po 35-40h, w Danii liczba godzin była 2-3 razy mniejsza - nauczyłem się bardzo, bardzo dużo. Wynikało to przede wszystkim z nastawienia na praktyczne projekty. Decydując się na studia na IFE, musimy jednak być pewni swojego angielskiego, bo od początku zajęcia prowadzone są w 100% w tym języku. Magisterkę z informatyki robiłem zaocznie na FTIMS, bo ze względu na pracę nie mogłem już sobie pozwolić na studia dzienne, a IFE zaocznych zajęć nie oferuje. To również bardzo dobry wydział, większość osób, z którymi pracowałem w różnych łódzkich firmach, kończyło właśnie informatykę na FTIMS-ie i mogę potwierdzić, że dużo się tam nauczyli :) Sama magisterka to już jednak rzecz na później, po inżynierce warto się zastanowić, czy faktycznie jest sens wybierać się na studia drugiego stopnia. Z mojej perspektywy dzisiaj odpowiedź brzmi "nie", ale to oczywiście kwestia indywidualna i każdy musi sam sobie na to pytanie w odpowiednim momencie odpowiedzieć. Jeżeli chodzi o możliwości stażu, to w Łodzi działa obecnie całkiem sporo firm, a duża część z nich organizuje staże i praktyki, także możliwości są :)

@@JakNauczycSieProgramowania Wielkie dzięki 😉

Dzięki! Myślę, że w pewnym momencie tak, ale raczej nie na przestrzeni następnych kilku - kilkunastu tygodni.

Poczekam. Na pewno będzie warto. 👍

Przeczytałem o tym podejściu tutaj: florimond.dev/blog/articles/2018/08/restful-api-design-13-best-practices-to-make-your-users-happy/ Spodobało mi się, bo faktycznie jest jednoznaczne i według mnie łatwiejsze do utrzymania w kodzie. Załóżmy, że chcemy wyświetlać użytkowników i posty (tak jak w przykładzie w filmie). Tworzymy dwa endpointy - users i posts, a jeden nie musi wiedzieć o drugim. Chcąc wyświetlić pojedynczego usera, korzystamy naturalnie z endpointu users/{id usera} Chcąc wyświetlić pojedynczy post, korzystamy z endpointu posts/{id posta}. I właśnie, tutaj dochodzimy do sytuacji, gdy chcemy wyświetlić posty danego użytkownika. Jeżeli zrobimy to zgodnie z ideą zagnieżdżania zasobów, otrzymamy adres: users/{id usera}/posts/{id posta} Ale tym samym powiązaliśmy ze sobą dwa endpointy - users i posts. Co jeżeli w pewnym momencie postanowimy zmienić URI dotyczące użytkownika i endpoint users otrzyma nową nazwę? Wtedy musimy dokonać też zmiany w endpoincie, który odpowiedzialny jest za wyświetlanie konkretnego postu. I pozostaje jeszcze pytanie, gdzie ten endpoint umieścić? Zakładając, że tworzę dwa pliki / dwie klasy - jedną dla endpointów powiązanych z użytkownikami, a drugą powiązaną z postami, gdzie powinien trafić ten users/{id usera}/posts/{id posta}? Chyba do postów, ale jednak "users" na początku adresu może być mylący. Przy querystringu ten problem znika - wiemy, że wyświetlamy posty, a parametry querystringa służą jedynie do filtrowania danych. Chętnie usłyszę jednak odmienne zdanie od mojego i podyskutuję :)

@@JakNauczycSieProgramowania dziękuję za link 💪

Zawsze możesz zwrócić JSONa z REST API, a dane do pliku XML zapisać już po stronie klienta. Wiele zależy również od tego, co wysyłamy i w jakich ilościach - przy pojedynczym requeście między JSON-em a XML-em może nie być zbyt dużej różnicy, ale przy kilku tysiącach requestów różnica w ilości przesłanych danych może iść w dziesiątki czy setki megabajtów. XML ze swoją strukturą, w której musimy mieć zawsze otwierający i zamykający znacznik, ma tendencję do osiągania naprawdę dużych rozmiarów. Co do sytuacji, którą opisujesz to pewnie, jeżeli takie jest wymaganie klienta, to możesz rekomendować inne rozwiązanie, możesz sugerować, że tak się nie powinno robić, ale jeżeli mimo to klient chce, żeby to wyglądało tak a nie inaczej, ostateczne słowo należy do niego :) W jednym z projektów, przy którym pracowałem, klient chciał, żeby każda odpowiedź z REST API, bez względu na to czy zakończyło się sukcesem czy nie, przychodziło ze statusem 200 OK, a informacja o sukcesie zapisywana była w jednym z pól zwracanego JSON-a. To wyjątkowo złe rozwiązanie, ale cóż, klient nie chciał słyszeć o innym :)

No właśnie, elastycznym rozwiązaniem jest, gdy klient potrafi wynegocjować z api format jakiego on potrzebuje. Może się posłużyć nagłówkami HTTP Content-Type. Wysyła, że chce xml, json czy nawet pdf w base64. Json robi się przeważnie domyślnym formatem, ale nie jest nigdzie powiedziane, że jest jedynym uznanym.

​@@pawewoszczyk5277 W REST API nie ma sztywnych reguł, to raczej zbiór rekomendacji, które ułatwiają tworzenie spójnych i łatwych do używania serwisów. Teoretycznie nic nie stoi na przeszkodzie, żeby wywołanie metody GET usunęło zasób z serwera, ale nie powinniśmy projektować naszego systemu w ten sposób. I tak jak w programowaniu mamy zestaw dobrych praktyk (zasada pojedynczej odpowiedzialności, unikanie powtórzeń, itd.), tak samo mamy zestaw dobrych praktyk przy projektowaniu REST-owych webserwisów i jedną z nich jest właśnie wysyłanie JSON-a w odpowiedzi.

Nie no jeśli nie stosowalibyśmy się do statusów odpowiedzi to nie robimy REST tylko coś najwyżej REST-opodobnego. Ja mówię tylko o formacie danych użytym w komunikacji. Jeśli wyobraziłbym sobie hipotetyczne ale całkiem możliwe do zrealizowania api, którego bym potrzebował do np. generowania QR-kodów, to nie miałbym problemów z nazywaniem go REST-owym, jeśli w odpowiedzi otrzymywałbym bezpośrednio dane pliku grafiki wraz z kodem 200 OK, a w przypadku błędów 400 Bad Request z jsonem z opisem błędów.

Jestem fanem tej nazwy od czasu, gdy obejrzałem jeden z odcinków Generała Italii ; )

Jak nauczyć się programowania haha, moi koledzy ze studiów są z Buczka, a odcinek nadrobiłem, klasa 😂😂

Na temat słów autentykacja i uwierzytelnianie toczy się gorąca dyskusja: www.rjp.pan.pl/index.php?option=com_content&view=article&id=263:autentykacja&catid=44&Itemid=145 sjp.pwn.pl/poradnia/haslo/autentykacja;13904.html edytornia.pl/poprawnosc-jezykowa/autentykacja-autoryzacja-i-uwierzytelnianie/ Ja wychodzę z założenia, że język polski nieustannie się zmienia i ewoluuje i autentykacja jest kolejnym słowem, które powinno bez żadnych przeszkód pojawić się w słowniku. Zwłaszcza ta technologiczna gałąź języka polskiego powinna być wyjątkowo elastyczna, bo bardzo dynamicznie rozwija się sama technologia, a język i słowniki powinny do tych zmian się dostosowywać. Mamy dzisiaj technologiczne/techniczne koncepty, które nie istniały jeszcze kilkadziesiąt czy nawet kilkanaście lat temu (lub istniały, ale mocno zmieniło się ich znaczenie), także nie możemy nieustannie odwoływać się tylko do słowników sprzed kilku dekad. Z uwierzytelnianiem mam ten sam problem, co z kwerendą w SQL - jakoś to słowo nie brzmi dla mnie naturalnie ; ) I tak jak w przypadku SQL, wolę mówić request zamiast kwerenda (swoją drogą chyba już nigdy po skończeniu studiów nie słyszałem, żeby ktoś użył słowa kwerenda :D), tak i w tym przypadku zamiast uwierzytelniania preferuję autentykację :)

@@JakNauczycSieProgramowania Ogólnie zaśmiecanie języka, to przyjmowanie bez namysłu wyrazów angielskich, kiedy mamy dobrze funkcjonujące odpowiedniki polskie. Rozumiem Twoje zdanie, jednak w tym przypadku nie mamy do czynienia z nowym, technicznym zjawiskiem, które nie ma nazwy. Moim zdaniem to trochę tak, jakby zamiast "słuchawki" mówić "hedfołnsy", bo tak nam bardziej pasuje. No okej, ale nie ma takiego słowa. O ile "request" to po prostu angielski wyraz, który nigdy nie będzie "rikłestem" i zawsze będzie stał obok polskiego "żądania", o tyle "autentykacja" jest zupełnie niepotrzebnie spolszczona, kiedy mamy już polski wyraz na to zjawisko. Podobna sytuacja ma miejsce z bazami danych - "query" nigdy nie będzie "kłeri" i dobrze funkcjonuje obok polskiego "zapytania" ("kwerenda" rzeczywiście trochę anachroniczna). Interfejs bardzo dobrze funkcjonuje - w pełni spolszczony wyraz, który nie miał polskiego odpowiednika ("międzymordzie" pomijam), nic nie zaśmiecił, a wręcz ubogacił język o nowe pojęcie. "Autentykacja" niestety nie jest tego typu wyrazem, stąd moja reakcja, a też już kilkukrotnie na branżowych konferencjach spotkałem się z przypominaniem o używaniu wyrazu "uwierzytelnianie", więc nie jestem osamotniony. Ale może tak tylko pieprzę; po prostu sprawy naszego języka ojczystego nie są dla mnie bez znaczenia :)

​@@NiceNick Oj, ja też zawsze bardzo mocno dbam o czystość polskiego języka :D Od lat konsekwentnie walczę z korpo-potworkami typu “meeting” czy “floor” i krew mnie zalewa, gdy słyszę takie zdania jak “mamy meeting na floorze”. W zasadzie jedynym tego typu korposłowem, które akceptuję jest “call”, bo tutaj faktycznie brakuje właściwego polskiego odpowiednika. Mamy telefon? Mamy telekonferencję? Telefon to zbyt szerokie pojęcie, telekonferencja z kolei sugeruje, że rozmawiamy w więcej niż dwie osoby, poza tym brzmi jak słowo z pierwszej dekady lat 2000 ; ) A mówimy “call” i od razu wiadomo o co chodzi. W przypadku słów typowo technicznym jestem jednak zdecydowanie bardziej liberalny. Wynika to przede wszystkim z tego, że w programowaniu to język angielski jest dla mnie pierwszym językiem. To w tym języku uczyłem się programować, to w tym języku studiowałem, to w tym języku czytam i oglądam 99% materiałów związanych z programowaniem. Gdy myślę i mówię o programowaniu, to w większości sytuacji robię to w języku angielskim, a język polski jest de facto tym językiem, na który to wszystko tłumaczę. I niejednokrotnie jest to trochę problematyczne - to co w języku angielskim brzmi zgrabnie, naturalnie i jednoznacznie, przy bezpośrednim tłumaczeniu lub szukaniu odpowiedników w języku polskim, zdarza się, że brzmi koślawo i sztucznie akademicko. Żartowałem nawet kiedyś, że to co było dla mnie największym wyzwaniem podczas pisania pracy inżynierskiej, to napisanie podsumowania pracy w języku polskim ; ) Całą pracę miałem po angielsku, ale wymagali dołączenia podsumowania już po polsku :) Co do tej autentykacji, to lubię to słowo z tego powodu, że tak jak mówię w 99% przypadków myśląc i mówiąc o tym koncepcie powiem “authentication”, więc autentykacja brzmi dla mnie znajomo :) A gdy usłyszę “uwierzytelnianie” przez chwilę muszę się zastanowić, co to słowo oznacza ; ) Oczywiście trochę koloryzuję, ale mam nadzieję, że łapiesz co mam tutaj na myśli :) Btw, bardzo fajna dyskusja i ogólnie ciekawy temat z tymi wszystkimi spolszczeniami, zapożyczeniami i czystością języka :)

@@JakNauczycSieProgramowania Zgadzam się, ciekawa dyskusja :)