Co sądzicie o granular degradation? Nasz backend łączy się z innymi aplikacjami ( ktore są nie stabilne ) i te apki nie zawsze trzymają się kontraktu ( czasami poleci null/undefined ). Mamy problem co zrobić w tym momencie, zabić cały request czy pozwolić frontendowi samemu wyłączać bloki ui które nie mogą być obsłużone przez zły kontrakt. Prawdopodobnie użyjemy .parse od zoda :D

A te Kursy to robocie, bo takie fantastyczne są zarobki, że aż po godzinach, zamiast się relaksować czy spędzać czas z żoną siadacie po kilku godzinach pisania kodu, analizy danych czy administrowaniu, przed kamerę monitor, obramianie filmu i masowo produkujecie kontent tak ? Nie wiem, jak inni, ja wolę, zamiast siedzieć dodatkowe kilka godzin przy montażu z oczami w monitorze. Spędzić czas z dzieckiem, ale jak nie ma kasy z tego IT, to rozumiem ze nie ma rady trzeba dorabiać. To jest ten dowód tego jak wspaniale jest w IT, że po pracy w IT trzeba jeszcze dorabiać ...

Jednak ta rozmowa kompletnie nie pasuje do sytuacji w 2024. Byc moze kilka lat temu te porady mialy by sens. Dzisiaj niestety branza IT przechodzi korekte i raczej ciezko o jakakolwiek prace dla nowych ludzu.

Aha, oprócz algorytmów trzeba sprawdzić "umysł", czy to "naukowy umysł programisty", czy zwykły "klepacz" (oczywiście na Juniora nie ma znaczenia, ale rozumiejąc różne "efekty" oraz nieliniowość procesu kształtowania [w tym kształcenia] umysłu i odróżniając go od procesu zdobywania wiedzy [niech pierwsza Julka z Ego jak Brazylia rzuci kamieniem jak wie! :D], to za 3 lata będzie całkiem inny programista, a za 5-10 lat to architekt najbardziej złożonych systemów, a może przyszły Tech Lead/ dyrektor IT, a później nawet prezes, bo WSZYSCY przyszli prezesi będą wywodzili się z IT/ AI i oczywiście znając filozofię, aby móc zrozumieć filozofię AI). Pytanie niby proste- co się dzieje w poniższym przykładzie (Java): int a = 5; Nienaukowy umysł odpowie: " liczba 5 zostaje przypisane do zmiennej 'a' typu int" (co oczywiście jest totalną bzdurą, bo nic takiego się nie dzieje [i nawet pomijając, że powinien powiedzieć 'cyfra'; oczywiście cyfra jest liczbą, ale to brak precyzji językowej [i/ lub niedbałość], czyli JUŻ widać nienaukowy umysł] ;) Takich pytań można mnożyć... Pozdrawiam! Czyli Lufthansa DE, chcąc płacić 9000 Euro szukała naukowych umysłów bez doświadczenia, a jeżeli ktoś szuka doświadczenia i nienaukowego umysłu i na tej podstawie płaci, to jest... idiotą; i nie- wcale nie można tego nazwać inaczej (oczywiście wyłączam SH, które walczą o przeżycie/ przetrwanie, bo "gaszą pożar", którego i tak nie ugaszą, a który spowodowali swoją głupotą, bo jadą na respiratorze, ale to już stan krytyczny/ agonalny, ale z doświadczonymi Seniorami jeszcze jakiś czas przeżyją, więc to- paradoksalnie- rozsądne [jedyne wyjście?], ale głupie od strony Seniorów, którzy się na to godzą; chyba, że na rok zarobić i się ewakuować ;) Ale jeżeli ktoś teraz w Polsce szuka "naukowych umysłów" i wielu talentów/ osobowości i chce ich pozyskać za 10-20k, to jest... idiotą, bo nawet jeżeli przyjdą [bo to ma jakiś sens "kontekstowy"], to zaraz zabierze ich mądra firma, bo przeskok będzie z 10-20k ,a 40-50k (albo i więcej), czyli dadzą Juniorowi doświadczenie i oszczędzą pieniądze... mądrym ludziom :D A jak Lufthansa płaciła 9k, to ile niby trzeba zapłacić, żeby kogoś od nich wyciągnąć? Poza tym jest coś takiego jak "granica ekonomiczna" i 9k dla Juniora, to już zapewnienie "przekroczenia jej", czyli pieniądze przestają mieć znaczenie (przy okazji widziałem ofertę polskiego oddziału zachodniego banku ~21k bez doświadczenia; na 3-6 msc ok. Jeżeli na dłużej, to... idioci ;) Ja bym zadał np. to pytanie: Dlaczego pojęcie "Klasa Abstrakcyjna" jest pojęciem błędnym i równocześnie właściwym? :D:D:D Ciekawe ilu Seniorów się wyłoży... ;) Albo dla Juniora/ Mid/ Senior: Dlaczego w ogóle możliwy jest zapis klasy anonimowej (z Interfejsu Funkcyjnego) w postaci Lambda? (od strony technicznej)

Poczytałem sobie komentarze i odsłuchałem ten film... Chcecie wejść do IT i tam się utrzymać??? To zadajcie sobie jedno ważne, ale to bardzo ważne pytanie: "czy lubicie się uczyć?" Ale prawie codziennie czegoś nowego (ja tak uczę się prawie całe życie- mogę spokojnie robić doktoraty z kilku dziedzin nauki, tylko jakoś zawsze miałem gdzieś papierki). Wtedy W OGÓLE nie interesuje Was co się dzieje na rynku IT, bo on przecież NIGDY się nie skończy (w sensie nie za naszego życia, chyba ;), tylko będzie się zmieniał. Oczywiście, że u nas jest wiele patologii społecznych/ uprzedzeń/ etc. i należy to uwzględnić, ale nie wszędzie i poza tym zostaje cywilizowany rynek zachodni (czyli języki obce). IT jest dla ludzi LUBIĄCYCH się uczyć (a nie siłą wepchniętych na studia) i coraz bardziej się tym staje i nawet u nas kończy się kabaret, czyli będą masowe upadki SH (a po co Niemcy mają im dawać kontrakty/ zlecenia, skoro programista z "naukowym umysłem" zrobi wydajność za pięciu??? Czyli obecną pracę "odtwórczą" [taśm produkcyjnych], które robiły nasze SH, zrobi programista z użyciem AI). Zaczyna się ekspansja na nasz rynek, co już widać po liczbie ofert z językiem niemieckim. Ale też widać oferty remote z USA (Senior Java 50k) Czyli jak ktoś lubi się uczyć, to dzisiaj siada i się uczy aż w końcu się nauczy na tyle, że go przyjmą, a skoro lubi się uczyć, to nie ma żadnego terminu, bo jak go przyjmą to... dalej będzie się uczył, bo co innego niby ma robić??? Poza tym w IT jest tyle do nauki, że życie to za mało, więc ma zajęcie do końca życia ;) Co za różnica co się dzieje na rynku, skoro ludzi o takich talentach i jeszcze lubiących się uczyć, to może jest 1-2% społeczeństwa??? (pomijam te narcystyczne firmy z Julkami w HR) Jeden kit... rynek nie zginie; co najwyżej będzie trzeba się douczyć, ale co za różnica, skoro lubicie się uczyć??? (polecam Python (zaczynam)/ Scala oraz już wchodzenie w AI/ ML/ NLP; tutaj nauki spokojnie na rok, żeby załapać podstawy). Inaczej odpuście sobie IT dla własnego dobra... bo to Was wykończy (tego jest MASAKRYCZNIE dużo). A jeżeli nie będziecie się uczyć, to Was zwolnią (kwestia czasu). Powodzenia! :)

dzisiejsi juniorzy nic nie umieja, ale do diversity hires to nie przeszkadza. duzo osob zaczelo klamac w cv. splywa milion ogłoszen, a poza tym to sie odechciewa mi aplikowac majac tyle expa, zeby jakas karyna z hr mnie przesluchiwala

Odnośnie uczelni... nie kumacie (ale u nas mało kto to rozumie). Chodzi właśnie o "naukowy umysł", czyli kluczowe jest "jaki proces kształcenia umysłu" się przeszło, a nie o samo zdobycie wiedzy. To nie są pojęcia tożsame. Więc, oprócz jakiś ewenementów/ wielkich talentów, odpowiednie studia będą wymagane i to już staje się normą i o tym mówię od dawna (a że materiał jest zbyt "mały" w danej technologii [bo studia KSZTAŁTUJĄ UMYSŁ, więc jest to wiedza z wielu zagadnień związanych z IT], to jeszcze najlepiej dodatkowo ukończyć ceniony Bootcamp (z danej/ konkretnej technologii), gdzie uczą "umysły naukowe", którzy już mają doświadczenie- np. od Sages). I nawet będzie to [studia techniczne- odpowiednio ukształtowany umysł] wymagane na stanowiskach nietechnicznych (jak SM/ PO/ PM/ AC, bo to inna komunikacja z zespołem/ między sobą, czyli dużo mniej błędów, czyli KASA, a przecież AI przyspiesza pracę, ale to- równocześnie- wiąże się ze zwiększeniem/ nawarstwianiem błędów logicznych, które są najtrudniejsze do wykrycia... i dlatego KLUCZOWA będzie komunikacja ;) I wiele innych spraw... :D

Z tymi algorytmami- i tak i nie.... Nie trzeba znać teorii tych algorytmów, ale mieć odpowiednio rozwinięty umysł algorytmiczny (tzw. "teoria umysłu", czyli wytworzony "naukowy umysł" w danej dziedzinie i ludzie interdyscyplinarni mają taki umysł w kilku dziedzinach, bo to inny sposób rozumowania). Dam przykład, gdzie jest to konieczne, bo to CZYSTE myślenie algorytmiczne, bo na "prosty rozum", to- na pierwszy rzut oka jest bez sensu: private static void getFrequencyNumber(List<Integer> list){ Collections.sort(list); // todo (2,3,3,3,4,4,4,5,6,36,49) - tak podświetla mi na żółto ;))) int nextElement = list.get(0) + 1; int frequency; for (Integer i : list){ if (i != nextElement) { frequency = Collections.frequency(list, i); if (frequency == 1) System.out.println( i + " występuje jeden raz"); else System.out.println(i + " występuje " + frequency + " razy"); } nextElement = i; } }

Jednego nie kumacie, co jest kluczowe- zmienia się rynek ("pivot"), czyli nawet jeżeli jest dużo mniej ofert, to nie oznacza, że należy zmniejszać wymagania finansowe, a wręcz przeciwnie, jeżeli ma się ku temu podstawy (i nie zalicza się do nich doświadczenie; zakładając powyższe, czyli pivot'a rynku, czyli iść do mądrej firmy ;) Dlatego jak najbardziej można wymagać średniej stawki Mid-a/ Seniora, będąc Juniorem (oczywiście już obytym, a nie po 5-10 msc nauki programowania ;), a tym bardziej na stanowiska nietechniczne (ale wymagające wiedzy z IT). A jeżeli argumentem jest brak doświadczenia w IT/ na konkretnym stanowisku (czy brak akceptowania patologii- to tyczy się powyższego), to są zwykli idioci i tyle (nie ma innego prawdziwego określenia); po co więc tam iść i się męczyć? Spory paradoks, ale tak jest i tak teraz będzie to wyglądać... *Ja zaczynam od stawki góra Mid-a/ dół Seniora (chyba, że SM/ PO/ etc., to od silnego Seniora). Jak odrzucą, to- paradoksalnie- BARDZO dobrze, bo długoterminowo, będąc w takiej firmie głupców (kult doświadczenia, czyli "wioska indiańska", zamiast umysłu/ osobowości), za kilka lat wypadnę z rynku razem z nimi; po co wchodzić na tonący statek z kapitanem- głupcem??? :D:D:D

Żeby dogłębnie zrozumieć programowanie (wytworzyć "abstrakcyjny świat w głowie" i wejść w ten "przepływ"), to potrzeba 2-3 lat... Żeby filozofię- potrzeba 10-15 lat i zacząć, gdy jest się nastolatkiem; inaczej to niemożliwe. Co jest dużo trudniejsze? ;))) Programowanie nie należy do najłatwiejszych czynności/ zajęć/ etc., ale robienie z tego filozofii/ fizyki kwantowej, to trzeba mieć poważnie poprzestawiane w głowie ;)))

Proszę o zaprzestanie rozprzestrzeniania postulatu o tym, że programista powinien zajmować się tym zawodem z "pasji". Jest to wysoce szkodliwe w każdym zawodzie, bo może prowadzić do wypalenia zawodowego poprzez spędzanie dużej ilości godzin w pracy poza pracą. Niestety nikt o tym nie mówi, ale pasja nie sprawia magicznie, że praca staje się prosta, jest dalej trudna, tylko początkowo lubimy co robimy, a potem i tak ludzie odczuwają negatywne emocje. A przede wszystkim warto spojrzeć na problem uzależnienia od pracy, w które bardzo łatwo się wpędzić z takim podejściem. Pracując z pasji, spędzając godziny w pracy po godzinach może skutkować tym, że ostatecznie pieniądze, które zarobimy bardzo szybko wydamy, ale na psychologa, który będzie pomagał uczyć się zdrowego podejścia do pracy i czerpania satysfakcji z innych aktywności. Na koniec jeszcze chciałem dodać, że pasja po łacinie "passio" oznacza cierpienie. Jeżeli chodzi o rozmowę, to wszystkie podcasty, które omawiają problemy pierwszego zatrudnienia są pozytywne dla nowych programistów. Jednakże warto też uświadamiać, że teraz naprawdę bardzo ciężko się dostać do branży, ponieważ od szczytu zatrudnień w 2022 zapotrzebowanie spadło ponad dwukrotnie. W każdym razie mam nadzieję, że osoby, które uczą się od dawna, czy studiują znajdą pracę, ale możliwe, że dopiero wtedy, kiedy polepszy się sytuacja ekonomiczna na świecie. Natomiast osobom, które nie miały nigdy nic wspólnego z IT i chcą się przebranżowić, to nie polecam przede wszystkim dlatego, że konkurujecie z około 13 tysiącami osób po studiach (rocznie), które mimo wszystko spędziły kilka tysięcy godzin na naukę i ciągle się rozwijają, a Ty jako osoba niezwiązana z branżą musisz to nadgonić i być lepszy. Powodzenia dla przyszłych programistów:)

Spotkanie frątasia z bakusiem 🤣

Panie Kamilu, a nie zastanawiał się Pan skąd ta wysoka korelacja między byciem dobrym programistą a szerokim pojmowaniem matematyki? Algebra, a więc i operacje na zbiorach w kontekście baz danych nic Panu nie mówią? Ale również grafika wektorowa? No tak, jest Pan backendowcem, więc pewnie nieco z tym gorzej. Ale zatem logika, włączając w to predykaty? Wnioskowanie w tak popularnej dziś "sztucznej inteligencji", czy systemach eksperckich? Prawdopodobieństwo? A blockchain oparty o złożone algorytmy szyfrowania? To serio nie jest matematyka?

Panowie, stwierdzenia zaczynające się od "rok 2024 będzie..." są nieco przeterminowane. Właśnie dobijamy do połowy 3 kwartału, i tak naprawdę bliżej nam do zabawy sylwestrowej aniżeli przebranżowienia w roku 2024.

Ta branża już dawno upadła. Pora wracać do grabienia.

Parę słów ode mnie jak wygląda obecnie wchodzenie do branży - parę lat temu znajomy się przebranżawiał na frontenda. Na rozmowie o pracę dostał zadanie stworzenia kwadratu (diva) a następnie pokolorowania tego diva na jakiś kolor i sprawienia, żeby po kliknięciu w ten kwadrat div zmieniał kolor na inny. Dosłownie TAKIE zadanie dało mu pierwszą pracę w it. Wprawdzie słabo płatną ale jednak - teraz jest seniorem w grubym korpo. A obecnie jak wygląda rynek ? Uczę się prawie dwa lata. Ogarniam, frontend, backend, bazy danych. Główną appke do portfolio robiłem jakieś trzy miesiące, mnóstwo logiki po stronie FE, BE, autoryzacja, technologie typu web sockets, asynchroniczne przesyłanie wszystkiego tam i z powrotem. Samo deployowanie tego to było spore wyzwanie, walka z CORSami, podpinanie storage itp. Wysłałem około 50cv, jedna rozmowa (ale na robote po godzinach, przy prywatnym projekcie więc nie wiem czy to nawet liczyć). Rekruterów nie interesuje portfolio, może maks parę osób na to zerknęło. No i pozytywne odpowiedzi (gdzie pozytywna odpowiedź to przejście do następnego etapu) dostałem wyłącznie z ofert, na które pasowałem, wysyłanie cv na stanowisko regular itp, to strata czasu wasza jak i rekruterów. Żeby nie było - ja się tutaj nie żalę, oraz nie mam zamiaru się zniechęcać - obecnie doszkalam się z technologii, które mi się jeszcze mogą przydać i za jakiś czas spróbuję ponownie. Ale obiektywnie - wejście obecnie do IT tak z marszu właściwie graniczy z cudem. Pozdrawiam

bo juniory sa rozkapryszone, z przerosnietym EGO i w wiekszosci przypadków cieńcy jak d..a weza... Rynek się zweryfikował i firmy pozbyły się aJailowych statystów.

Rozmowa z gościem który sprzedaje kursy i z tego żyje xD Jak chcecie poważnej i normalnej rozmowy do podbijcie do jakiegoś mida/seniora który faktycznie pracuje jako programista i nie chce wam nic sprzedać.

Dobra, doszedłem do 22 minuty i już mi wystarczy. Ci goście są idealną reprezentacją powodu, dla którego w branży IT jest źle. Głupoty które mówią: 1. Wysyłaj CV na regulara będąc juniorem - absurd, szczególnie obecnie. Ci goście powiedzą Ci że masz spamować swoim CV oferty na nie Twój poziom. Odpal sobie filmik z byle jaką Julką HR i ci powie że takie spamowanie to największy rak. 2. Junior na siebie nie zarabia. Taaa, szczególnie w polskich SH, gdzie juniorzy są outsource'owani na potęgę. Zawsze, w każdym projekcie jest pula prostych tasków które junior robi i przynosi to wartość firmie. Inaczej zrobiłby to regular albo senior, może i w krótszym czasie, ale dostałby też więcej za godzinę. I ten ego tripping że przez rok to ty nawet nie jesteś juniorem tylko jakimś trainee. Zjedzcie na ziemie i przestańcie podbijać sobie swoje ego że macie przecież tyle lat expa, a wasz pracodawca to taka prze-firma ze nowi powinni w ogóle dokładać że maja prawo pracować. To jest normalna praca biurowa, tylko że dostajemy europejskie stawki. A wy tutaj (jak większość programistów) próbujecie sprzedawać bajki o wybitności branży. No ale kursy same się nie sprzedadzą.

Ciekawa rozmowa, jestem widzem Kamila i zastanawia mnie jedno, po stwierdzeniu prowadzącego, że trzeba umieć algorytmy, wiedzieć o grafach itp. Stąd nasuwa się pytanie, czy prowadzący w jakimkolwiek stopniu miał doswiadczenie z wykorzystaniem teorii grafow skoro zajmuje się frontendem?

kanał złoto :)

Cześć. Wg mnie poruszasz super tematy, masz świetnych gości, ale powinieneś popracować nad jakością swoich wypowiedzi. Budować bardziej zwięzłe zdania nasycone bogatszą treścią. Ot takie spostrzeżenie. Pozdro i rozwijaj się dalej :D

Ja podobnie. Działam w Angularze i eventy wyglądają tak: (pageChanged)="onGridPageChanged()" (valueChanged)="onUserValueChanged()" (click)="onAddButtonClick()" I teraz najważniejsze: wszystkie metody z prefixem "on" mówią o tym, że jest to reakcja na zdarzenie, które wystąpiło w templatce. Przeglądając kod od razu wiemy jakie są event handlery. Unikam czegoś takiego: (click)="add()" Dodatkowo metody wspomniane wyżej np. "onAddButtonClick()" są protected, dzięki czemu są widoczne w templatce, natomiast gdybyśmy chcieli dostać się do instancji komponentu to te metody są ukryte. Całe Flow: (click)="onAddButtonClick()" protected onAddButtonClick(): void { this.openAddUserModal(): }

Dobry pomysł z taką krótką treścią :) Odnośnie nazewnictwa - stosuję tak samo :)

Siema, dobry materiał. Używam reacta. Konstrukcji handleSaveDevice nigdy nie widziałm, dziwnie to dla mnie wygląda, nazwa saveDevice jest bardziej naturalna. 1. Ja w parencie daje albo saveDevice, albo jak mi saveDevice spuchnie to robie tak: const saveDevice = (x) => { ... }; const handleButtonClick = (x) => { {...} // display spinner, disable button etc... saveDevice(x); {...} // np close modal, display toast etc... }; Dużo zależy czy komponent child jest reużywalny, czy jest ściśle związny z parentem. Jeżeli jest integralną częścią parenta to ja bym się nie bał dawać handleButtonClick. 2. W opisie jest wspomniany "setUserState" w filmiku nie widzę wytłumaczenia co z tą nazwą jest nie tak. Czy handling eventu w child jest złą praktyką? (State trzymany w parencie, czyli updatujemy stan parenta w childzie poprzez właśnie setUserState)

Fajna, spójna konwencja. Sam na początku stosowałem onClick={handleClick} Albo nawet ={onClick}.

Ciekawy materiał. Mało jest dyskusji na temat DDD na froncie, być może dlatego, że trudno określić, co właściwie stanowi logikę biznesową na froncie. Mimo to brakuje dyskusji na temat architektury na froncie. W kontekście materiału: 1. W dyskusji wspominacie o podziale na domeny, subdomeny i bounded context’y. Warto dodać, że zazwyczaj domeny funkcjonują w obszarze definicji problemu. Bounded context’y to przestrzeń rozwiązania/implementacji. Innymi słowy, jedna domena może być później objęta kilkoma bounded context’ami. 2. Często domeny pokrywają się z oddziałami w firmie (prawo Conwaya), choć to tylko jedna z heurystyk. 3. W dyskusji nie pojawił się termin agregatu, który jest kluczowy na poziomie implementacyjnym w DDD. 4. Warto wspomnieć o zaletach DDD. Wydaje mi się, że nie jest to jasne dla każdego. Większość architektur dzieli kod na trzy obszary: UI/Prezentacja, Infrastruktura, Domena. DDD pozwala wygodnie wydzielić te warstwy i je uporządkować. Każda z nich może być w idealnym wypadku testowana i rozwijana niezależnie. Kluczowym elementem jest testowalność. Na frontendzie testy wciąż są tematem dyskusji, gdzie opinie są skrajne: od "nie testować wcale" do "testować wszystko". Prawda jest taka, że rzadko spotyka się testy na frontendzie. Większość osób powie, że “nie wie jak to zrobić”. Napisanie testu jednostkowego jest trudne, jeśli kod jest pomieszany z hook'ami, context'ami i innymi elementami frameworku. Samo pojęcie “jednostki” na frontendzie jest problematyczne (wiele osób przyjmuje, że na frontendzie mamy głównie testy integracyjne - testing trophy Kenta C. Doddsa). Najczęściej spotyka się kilka testów e2e, które zawsze można napisać. 5. W kontekście DDD na froncie trudno określić, co jest logiką, którą faktycznie należy oddzielić od UI. Wydaje mi się, że możliwe jest oddzielenie logiki od frameworka, ale należy przedefiniować pewne pojęcia z DDD. Chcemy osiągnąć to, co DDD oferuje, ale na poziomie kodu (poziomie taktycznym) musimy użyć narzędzi odpowiednich dla frontendu. 6. Nie jest istotne, czy wykorzystujemy Clean Architecture, Porty i Adaptery, Architekturę Heksagonalną, czy Onion Architecture. Wszystkie te podejścia wydzielają logikę biznesową do osobnej warstwy. W pewnym sensie idea DDD została zweryfikowana przez wielu architektów/autorów dochodzących do podobnych wniosków. Każda z tych architektur używa różnych terminów, ale idea pozostaje taka sama. 7. Trudno nazwać jakąkolwiek architekturę “czystym DDD”. Zawsze musimy sami zdecydować, jak bardzo warstwy UI, infrastruktura, domena powinny być od siebie rozdzielone. Im bardziej są rozdzielone, tym więcej mapowania i abstrakcji musimy wprowadzić do kodu. Musimy zachować pewien pragmatyzm, co często jest trudne. Pod kątem aplikacji serwerowych Martin Fowler w książce “Patterns of Enterprise Application Architecture” trafnie opisuje 3 podejścia do organizacji logiki biznesowej: a. Wynieść logikę biznesową do ogólnego serwisu. To rozwiązanie spotyka się w wielu aplikacjach (OrderService itd.) b. Zbudować model domenowy, który pełni rolę modelu relacyjnej bazy danych, np. używając ORM’a. W pewnym sensie mieszamy model domenowy z modelem infrastrukturalnym (modelem persystencji). c. Stworzyć model domenowy zupełnie osobny od modelu bazodanowego - rozwiązanie najbardziej pracochłonne, dające pełną niezależność od warstwy persystencji. Innymi słowy zawsze my decydujemy jako bardzo chcemy "być DDD" - zapewne w wielu projektach świadome użycie jedynie kilku elementów DDD jest jak najbardziej w porządku. Trzeba tylko mieć czysty zamysł co chcemy osiągnąć vs kopiowanie danego wzorca bez zastanowienia się dlaczego właściwie jest mi on potrzebny. Wybaczcie, że tak się rozpisałem. Ostatnio sam dosyć sporo czasu poświęcam nad integracją DDD w kontekście aplikacji frontendowych. Dziękuję za materiał :)

Ten "useProject" hook w 1:10:00 powoduje nie potrzebne przerenderowanie. Po wyrenderowaniu sie komonentu ktory posiada "useProject", setter setProject w useEffecie spowoduje kolejne przerenderowanie sie komponentu zaraz po jego wyrenderowaniu. To samo stanie sie gdy jedno z deps sie zmieni. Wiadomo nie wpływa to znacznie na performance ale gdy buduje się jakieś API pod reacta to na takie rzeczy się patrzy. Dobrze ze trwają prace nad React Compiler ;)

O jaaa, zaczalem sluchac do snu ale musze przestac bo jest zbyt ciekawe i moge zaraz miec problem z zasnieciem :) jutro dokoncze! Pozdrawiam

Ciekawa rozmowa, a co do 32:36 to przecież wyjazd z pracą w różne miejsca może mieć wiele różnych form. Leżenie na plaży to mało kreatywna opcja, ale jak ktoś woli to i może tak być, ale wiadomo, że praca musi być w dobrych, komfortowych warunkach z miejscem na laptopa albo w coworkingu. Pomysły - wyjazd tam gdzie jest śnieg, gdy u nas go nie ma, wtedy jeździsz na nartach przed / po pracy albo w weekendy, dłużej niż tydzień na ferie. Możesz tak przedłużać sobie długie weekendy z pracą pomiędzy. Albo wyjazd, gdzie jest cieplej gdy u nas jesienna plucha i śmigasz sobie na rowerze czy chodzisz po górach - tak samo jakbyś to robił w domu po pracy, ale jest lepsza pogoda. Ktoś lubi plażę - proszę bardzo, wyjazd na surfing i nie narzekasz, że "o jeszcze pół roku do wakacji", a masz te miejsca na zawołanie, a pracujesz normalnie jak i w domu - szukasz coworkingu albo wynajmujesz droższe miejsce z biurkiem, o ile to możliwe. To są ogromne korzyści pracy zdalnej i pracy jako programista / w IT i jeśli dla kogoś takie zajawki po pracy są ważne, to może i nie być wielkim pasjonatem IT, ale będzie to robił, bo pozwala to na życie na w miarę własnych zasadach.

Poproszę nazwę kapeli, bo nie udało mi się odpowiednio zrozumieć :)

Koleś nie odpowiada na pytania ,nie potrafi w prosty , czyli najskuteczniejszy sposób przekazać informacji . Komunikacja z taką osobą byłaby baaaardzo trudna

Może ja na seniora powinienem pójść jak Adam jest "MID"

kzbin.info/www/bejne/oYmnoWtmmsato9E Nie bardzo rozumiem, metoda push() zwraca długość tablicy (czyli ten number) ale funkcja strzałkowa z {} zwraca undefined (ta z implicit returnem zwraca to co zwraca jej kod) ale na nagraniu Mateusz tylko zmieścił to w jednej linijce ale nie usnął klamer, więc usunął tylko spacje, czyli ta funkcja zwracała undefined jak była rozbita na 3 linijki i jak była zapisana w jedne linijce bo usunęliśmy tylko znaki nowych linii i spacje.

kzbin.info/www/bejne/oYmnoWtmmsato9E Dlaczego w komponentach lepiej używać customHooków a nie wywołań funkcji?

kzbin.info/www/bejne/h4japYqiqK5lrqc Katalogi grupujące per typ - liczba mnoga Katalogi grupujące domenowo - liczba pojedyncza? (pytam bo na nagraniu powiedziałeś liczba mnoga) Nie rozumiem też do końca czym się różnią komponenty w katalogach components od komponentów w katalogach containers kzbin.info/www/bejne/h4japYqiqK5lrqc - Dlaczego nie trzeba zmienić rozszerzenia pliku na jsx?

Jaka jest przewaga tego podejścia, że w projekcie react robimy katalog shared > ui > Burger w którym umieszczamy pliki : index.js (export * from './public-api.js' public-api.js (import Burger from './Burger' export Burger from './Burger') Burger.js (z kodem exportującym komponent Burger) Dlaczego nie exportować bezpośrednio z burgera albo bezpośrednio z public-api.js? Rozumiem, że to chodzi o to, że jakby było więcej komponentów Burger ale w takim razie dlaczego pośredniczący plik public-api.js a nie od razu index.js?

Nie bardzo zrozumiałem podejście do tłumaczeń, czy mógłbym prosić o jakiś artykuł co miał Pan na myśli? I ten fragment o komponentach również.

Chce przerobić całą serie, chciałem na początku poklikać sobie po aplikacji aby zrozumieć jak działa, sprawdziłem z linku w opisie i zaczęły się problemy: - w readme są 2 dema podane (rozumiem, że chodzi o drugie) - pasy podane w readme do zalogowania się nie działają (zarejestrowałem nowe konto przy pomocy 10minutemail) - zmieniłem język na polski i przy dodawaniu gdzie mam wybierz jednostkę, mam zaznaczone piece (nieprzetłumaczone) i kiedy chce dodać produkt pisze, że trzeba wybrać jednostkę (nie może być wybrane piece) - produkty się nie dodają - kiedy przechodzimy z pierwszej strony na kategorie produktu i klikamy add something to wybrana jest kategoria pieczywo (bez znaczenia z jakiej kategorii przeszliśmy - tryb ciemny ma moim zdaniem tragicznie dobrane barwy Czyli ogólnie aplikacja jest totalnie broken Ale widzę, że commity są z zeszłego miesiąca więc pewnie demo jest nie odświeżone

Mega wartościowa rozmowa 😃

To centrowanie w pionie - to był trick z display: table i table-cell na dzieci . Wtedy dzialal vertical-align:middle na divy ;d Troche z czapy dzisiaj pytanie, ale rozumiem ze daje swiadomosc czy ktos zna CSS sprzed flexboxa gdzie CSS to byla rzecz na ktorej trzeba bylo sie chwile zastanowic :D

Po tej rozmowie nabrałem dużego szacunku dla osób rekrutujących. Nie umiałbym zachować powagi podczas takiej rozmowy gdy padają różnego typu absurdy, albo po prostu lanie wody. Co z perspektywy rekrutowanego jest oczywiste i zrozumiałe - mówisz co wiesz / to co ci przychodzi do głowy - ale jednak znając odpowiedź ciężko się powstrzymać przed facepalmem czy nawet uśmieszkiem :P

Dobra i ciekawa rozmowa Panowie, miło się słuchało! Temat(y) bardzo istotne, "przyglądam" się im z bliska stale w branży i fajnie, że publicznie opisywane są te wyzwania, które wielu z nas dopadają :) 5.

Wszystko fajnie, ale przy sekcji "testing" widzę rozjazd z trendami. DORA metrics mówi jasno, im częściej i szybciej wdrażasz na produkcję, tym większa jest jakość. A tu padło stwierdzenie, że trwa to długo, bo testerzy sprawdzają. Dlaczego nie ma zaufania w automatycznych testach akceptacyjnych? Dlaczego nie ma shift-left? Dlaczego mowa jest o rozbudowywaniu testów end-to-end, skoro od dawna wiadomo, że jest to zła praktyka? Odpowiedź na te pytania jest prosta: testy frontendu to ciągle terra incognita. Unit testy bardzo często nie dają wartości, a nawet obniżają prędkość developmentu (a powinny podnosić). End-to-endy są flaky i za grosz nie można mieć do nich zaufania. Chciałoby się robić TDD na froncie, ale założeniem TDD jest to, że można refactorować kod, a testy się nie zmieniają.

Nietechniczny ale mega fajny odcinek!

A jak dla mnie, to gość się nasłuchał kilku doświadczonych gości i powtarza bez zrozumienia. Podzielam zdanie poprzedników mocny junior z aspiracjami na mida jak uzupełni podstawową wiedzę. Imho przy kodowaniu czegoś by wyszło. Teraz już wiem dlaczego nie szukają nigdzie juniorów - nagle każdy jest seniorem. WOW

rzeczywiście .... zmiana 5 razy pracy w perspektywie 6-7 lat to sukces. Tak samo jak ogromna liczba rozmów o pracę. Ten pracownik o którym mowa to nie ma co robić w domu czy lubi chodzić na rozmowy kwalifikacyjne? W cholerę posłałbym takich pracowników jeżeli co roku zmieniają pracę. Druga sprawa - czy Panowie mówiąc o CV mówią o nim jako jedynym dokumencie rekrutacyjnym? W wielu branżach mamy jeszcze wymagania dyplomów ukończonych szkół/uczelni oraz listy motywacyjne. I tam pewne inf. będę się powtarzały więc jaki jest sens ich umieszczania w CV skoro są w liście motywacyjnym.

Ten gościu jest mentorem? on najwżniejszych rzeczy z JSa nie ogarnia nawet :D

Bardzo spoko odcinek. Widać po Sebastianie, że pomimo wielu lat w branży nie wypalił się i wciąż z dużym zainteresowaniem podchodzi do swojej pracy. Ładna miejscówka na nagrywanie!

Czyli dochodzimy do momentu pt. "Jak podkoloryzować CV, żeby HR miał mokro w majtach". W każdym razie super odcinek, fajne rady, na pewno skorzystam. Jest ciężki okres, mało ofert pracy, dużo kandydatów - większość ludzi z doświadczeniem i skillem, a jednak HRowcy (bez wiedzy technicznej) to największa przeszkoda na drodze kariery w IT. Na marginesie: Ostatnią rozmowę techniczną przeszedłem bardzo dobrze, ale żeby ją dostać i przebić się przez HR-ów, to myślałem że trzeba mieć szczęście. Okazuje się, że wyobraźnia i stek bzdur o optymalizacjach i skracaniach czasu procesów więcej zdziała. Jakość i czytelność kodu > czas działania procesu, tego chyba nikt nie powiedział Panu Tomkowi. Już lepiej byłoby wyznaczyć krótkie zadanka do rozwiązania przy składaniu CV i dawaniu HRom do sprawdzenia. Jak zrozumieją co tam się dzieje, znaczy że kandydat może iść dalej w rekrutacji :D