วีดีโอ

Kod z 01:00:00 z Dequeue z miejsca łamie LSP :D Przynajmniej w takiej formie jaką podaliście. Dequeue jest kolejką dwukierunkową a queue jest jednokierunkowe. Nie da się użyć Queue w przypadku gdybyśmy chcieli ją użyć w kontekście Dequeue (nie da się podmienić bez efektów ubocznych).

Szacun za wyszczególnienie typów i dziedziczenia. Właśnie tu chyba tkwi moim zdaniem nieporozumienie. Meyer propagując żywo i dyskutując publicznie o dziedziczeniu dużo pisze o warunkach jego używania (artykuł how to not use inheritance ze strony archive eiffel). Napisał tam: -------------------------------------------------------------------- "Is-a" rule of inheritance Do not make a class B inherit from a class A unless you can somehow make the argument that one can view every instance of B also as an instance of A. -------------------------------------------------------------------- In other words, we must be able to convince someone --- if only ourselves to start with --- that "every B is an A" (hence the name: "is-a"). Dodatkowo w pracy "Genericity versus Inheritance" z 1986 już w samym abstrakcie pisał, że generyczność i dziedziczenie to DWIE RÓŻNE/alternatywne techniki do osiągnięcia reużywalności, rozszerzalności i kompatybilności w tworzeniu komponentów oprogramowania. Dziś w językach udostępniających obie techniki często łączy się je. Programiści często tworzą sztuczne abstrakcyjne byty widmo, które nie tworzą żadnych pojęć (nie reprezentują żadnego rzeczywistego pojęcia). I to jest błąd bo takie uogólnianie ma sens jak poświęci się czas na stworzenie solidnego ADT (czy polskie ATD) w którym wyodrębnia się te pojęcia a następnie opakowuje się je w język programowania. Samo stosowanie reguły "is-a" czyli semantycznej zgodności nie wystarczy do zrobienia dobrego dziedziczenia (przykład z kwadratem dziedziczącym po prostokącie). Dlatego stosować powinno się też LSP. Meyer dodatkowo uzupełnia w swoich pracach koncepcję LSP od Liskov wprowadzając DbC które wprowadza warunki wstępne, końcowe i inwarianty wzmacniające lub utrzymujące kontrakty bazowe.

Z LSP sprawa jest banalna: Barbara Liskov sformułowała zasadę, zgodnie z którą obiekty klasy bazowej powinny móc być zastąpione obiektami klasy pochodnej bez skutków ubocznych​. Częste nieporozumienie polega na tworzeniu hierarchii, w której podklasa formalnie jest podtypem, ale nie spełnia kontraktu nadklasy. Klasyczny przykład: dziedziczenie Square (kwadrat) po Rectangle (prostokąt). Matematycznie kwadrat jest szczególnym prostokątem, jednak w kodzie narusza LSP - jeśli klasa Rectangle pozwala ustawić niezależnie wysokość i szerokość, to obiekt Square zmuszony do zachowania równości boków będzie działał niezgodnie z oczekiwaniami klienta. Taki kod sprawi niespodzianki: class Rectangle { protected int width, height; public void setWidth(int w) { width = w; } public void setHeight(int h) { height = h; } public int area() { return width * height; } } class Square extends Rectangle { @Override public void setWidth(int w) { super.setWidth(w); super.setHeight(w); } @Override public void setHeight(int h) { super.setWidth(h); super.setHeight(h); } } // ... gdzieś w kodzie klienckim: Rectangle rect = new Square(); rect.setWidth(5); rect.setHeight(4); System.out.println(rect.area()); // oczekiwane 5*4=20, otrzymane 4*4=16 - niespodzianka! Mimo że Square „jest” prostokątem z punktu widzenia dziedziczenia, nie zachowuje się jak prostokąt w użyciu. To złamanie LSP. Wniosek: Dziedziczenie musi zachowywać kontrakt nadklasy. Jeśli podklasa potrzebuje zmienić podstawowe założenia działania klasy bazowej, to znak, że hierarchia jest błędna. Należy wtedy przeprojektować relacje - np. uczynić obie klasy osobnymi bytami implementującymi wspólny interfejs (np. Shape z metodą area()), albo wykorzystać inne mechanizmy (np. Decorator lub parametryzację zamiast dziedziczenia).

Pierwszy problem nie dotyka w ogóle problematyki dziedziczenia tylko złego zastosowania tegoż. Otóż w 8:54 mamy kod który ma odwrotną i nielogiczną hierarchię dziedziczenia. W tym kodzie AccountRetrieveModel dziedziczy po AccountCreateModel, a ta z kolei dziedziczy po AccountUpdateModel. Taka hierarchia jest nielogiczna z perspektywy semantyki: Model do odczytu (Retrieve) przejmuje cechy modelu do tworzenia (Create) i aktualizacji (Update). Model do tworzenia (Create) przejmuje cechy modelu do aktualizacji (Update). W praktyce to wymusza posiadanie w klasie Retrieve pól i logiki, które tak naprawdę służą do innego celu (lub w ogóle nie powinny tam być). To narusza SRP, porządek semantyczny i utrudnia rozbudowę, ale to nie jest problem wynikający z dziedziczenia, tylko z złego jego stosowania. Dodatkowo tu jest problem z wykorzystaniem dziedziczenia w niewłaściwej warstwie.

Czemu koszyk ma swoją tożsamość - w sensie Guid? Czy koszyki są wyszukiwane w tej domenie jakoś? Nie powinien to być VO?

Dobrze się Was słucha! PS. Chętnie zobaczę porównanie narzędzi AI pomagających w wytwarzaniu oprogramowania w waszym wydaniu. Sam robiłem już kilka porównań u siebie, ale np. Cursor AI się nie bawiłem, a ufam waszej opinii, więc zaoszczędziłoby mi to czasu :D Więc +1 dla takiego materiału :D

super forma, fajnie ze za mały grosz dajecie tyle info dla AI. Jednak to człowiek wilkiem był dla człowieka, ale na szczęście szybszego wilka tresujecie.

95% migracji z FluentAssertion do Shouldly to Find: Should(). Replace with: Should i to za 130$ miesięcznie :D

Fajna była dyskusja gdy próbowaliście trochę określić "samych siebie", czyli wasz kanał. O czym tak naprawdę jest i dla kogo, i jaką wartość niesie, np w kontraście do Nick Chapsas (btw jego kanał też lubię i oglądam). Ale dlaczego piszę.... ZACHOWAJCIE SWOJĄ FORMĘ proszę :) To jedyny wartościowy kanał do którego mam zaufanie i sympatię gdzie mogę posłuchać, zastanowić się, dowiedzieć tych wszystkich rzeczy dookoła, które tak naprawdę są źródłem do wszystkiego co dalej się robi podczas pracy jako developer. Wg mnie Wasze dygresje są super, niosą wartość i trochę humoru. Pokazują.. "o jednak nie tylko ja się z tym zmagam". Macie kanał z materiałem który bym opisał jako KLEJ (te wszystkie "szczegóły implementacyjne" nabierają sensu, poco ale i Skąd się wzięły) i SMAR (dobrze usłyszeć od innych, doświadczonych, że kompromisy w developmencie są normalne) do pracy developera. Tak Trzymać! Pozdro! ;)

Odnośnie migracji z FluentMigration -> u nas w firmie ktoś puścił stosowne zapytanie na AI, który wygenerował odpowiedni skrypt migrujący. Szybka piłka i po zabawie.

Jak ta Specyfikacja ma się z Ardalis Specification nugget package?

Rozwiązywanie problemów > techniczne fapanie 🫶

I niech sie baza dla AI konczy, AI ma byc tylko dodatkowym narzedziem :D

Super format. Dobrze się słucha! :) Fajnie, że robicie content!

Idziemy w złym kierunku :) Wszystko rośnie a XP maleje :/ Wymagania Windows 95/XP/Vista czy 11 :) no tu mówimy o kilku rządach wielkości… Apka na srajfona czy andruty no ja rozumiem kilkanascie czy kilkadziesiąt MB ale nie 300-500MB za jakąś prosta apke…

Jak dla mnie DeepSeek to jest tajna inicjatywa rządu chińskiego. Skoro im się udało to opublikowali, co od razu spowodowała znaczące zawirowania na giełdach i spadki akcji amerykańskich firm jak Nvidia, która jak można przeczytać w mediach z dnia na dzień traci pół biliona dolarów

Panowie, myślę że żyjecie trochę w bańce, że wszyscy używają AI. Jest całkiem sporo instytucji gdzie jest to poblokowane, a nawet Reddit i sporo blogów techniczny. Wtedy zostaje SO. Jeszcze spora grupa ludzi jest która z AI nie może skorzystać....

Testy AI - dobry pomysł :D

Co stało się z Piotrkiem? Czy już definitywnie zakończyliście współpracę?

indeed.

W większości przypadków nie ma potrzeby przepisywania z FluentAssertions na Shoudly, która zmusiłaby firmy to kupowania licencji. Mogą po prostu zostać przy wersji siódmej. Jakie nowe killer ficzery mogą pojawić się w "bibliotece opakowującej ifa"? Ok, powiedzieliście to 3 minuty później, ale zostawiam dla zasięgów!

Cześć, aktualnie dostępny jest Prometheus 3.1.

🔗 Linki do newsów: devmentors.io/it-news/ep-14/

Ale uprościłeś mi życie z tymi search w repository! Fajny jest ten pomysł, źe po co mi ten domen w query który nie powinen zawierać biznesowej logiki?! ❤

tym wróżbitą kodu zostanie SonarQube 😆

Dopóki biznes nie chce za takie rzeczy płacić to nikogo to nie interesuje :D

Jest mega! Dzięki ❤

Tam gdzie wydajnoac nie jest istotna, tam nie trzeba potrafic takich rzeczy. Ale gdyby nie osoby znajace assemblera i c to python by nie istniał xD

Wg mnie warto nauczyć się jak działa masstransit choćby po to żeby zobaczyć czego będzie brakować jak już trzeba będzie zrobić własny ulep (i wtedy zobaczymy że jest tego w c… i nie warto). Moje podejście to zawsze startować z masstransit i zmienić tylko jeśli faktycznie nie będzie się dało obejść jakiejś abstrakcji.

"takim białkowym" 😂❤

Jeśli chodzi o scheduling to MassTransit wspiera też natywne mechanizmy Rabbita/Azure Service Busa itd

Fajne, przystępne i dowiedziałem się czegoś nowego. Dzięki Panowie!

MassTransit można skonfigurować tak, żeby nie opakowywał wiadomości w kopertę.

Super materiał - pozdrawiam Panowie BTW wyciągnijcie Piotrka z szafy :)

czapka LP, masz u mnie +1000 do respektu :D

Dlatego ja odszedłem od webówki. Webówka poszła w złym kierunku. Jest masa gotowców, ludzie nawet nie wiedzą jak to działa, często nawet nie znają podstaw, ale są w stanie robić jakieś strony szybciej i taniej, więc zgarniają klientów. Kod zajmuje 10 razy tyle ile powinien zajmować, bo zawiera w sobie biblioteki, które zawieraja pierdyliard zbędnych funkcji, ale klient nie jest tego świadomy, a gdy się coś wykrzaczy to bida... Biblioteki w każdym języku mają sens, kiedy przygotowuje się je samemu i zawierają tylko to, co realnie dany programista używa. Obecnie ogarniam mikrokontrolery i nawet głupia funkcja zmieniajaca stan na wyjściu zawiera jakieś pierdoły, które zbędnie zajmuja kilkadziesiąt bajtów cennej pamięci. Dlatego lepiej zrobić to w asemblerze i zmieścić sie w jednym bajcie...

czapke z daszkiem jeszcze jakos zrozumiem, ale wytlumaczy mi ktos o co chodzi tym youtuberom z siedzeniem w domu w zimowej czapce?

@DevMentors w jakim hackathonie braliście udział?

timeline zwiększy oglądalność...

Patrzymy też na wydajność rzeczy w kontekście ich funkcjonalności. Wystarczy logicznie potrzeć co było oferowane na sprzęcie w dawnych latach i co było możliwe (przecież jak komputery były ziemniakami to jednak powstawały dobre gry, a programy miały dalej dużo funkcji) a jak jest teraz. Mamy sprzęt z kosmosu, można na nim często stawiać LLM, robić cuda, tymczasem coś tak prostego (w porównaniu do faktycznie złożonych obliczeniowo rzeczy) jak wyświetlenie IDE zajmuje zdecydowanie za długo. Już nawet nie chcę się silić na porównanie szybkości procków z dawnych lat do obecnych i o ile tysięcy % są szybsze, a nie potrafimy (jako programiści) tego wykorzystać, tylko staramy się zrobić wszystko aby było łatwiej programowalne.

Format jest świetny a pogadanki naprawdę wartościowe, brakowało mi takiego kanału jak wasz w polskim języku. Robicie świetną robotę :)

Od kiedy ilość funkcjonalności i jakość produktu ucina się na rzecz terminów i pieniędzy, a nie na rzecz performance dzieje się to o czym była mowa w podcaście z Casey. Przez większe pieniądze w branży obniżyliśmy próg wejścia do branży aby móc przerobić zapotrzebowanie, często kosztem jakości. Póki klientem jest zwykły człowiek to można nie dbać o wydajność, niezawodności, byle żeby być pierwszym na rynku z funkcjonalnością X. Jak klient jest przyzwyczajony do słabej jakości za kwotę X to po co to polepszać (patrz cały Microsoft, ludzie płacą bo alternatywy nie są popularne/dużo lepsze). Trochę patrzycie jednostkowo na ten cały problem. "Ja robię x w pracy i tam nie ma problemów, że nie znam tego czy tamtego". No trochę tego nie wiesz, bo właśnie nie znasz. Dalej są branże gdzie dba się o jakość takich rzeczy i pieniądze nie są jedynym wyznacznikiem (np. lotnictwo). To jest trochę tak, że Casey jest na tym rynku dużo dłużej, widział sytuację przed wielkim otwarciem progu wejścia do IT i po. Widział jak coś robione z chęci i pasji przerodziło się w pogoń za terminami.

Chyba pomyliliście Hip-hop z IT

Nie wiem skąd ta niechęć i oburzenie programistów jak usłyszą że muszą poznać budowę sprzętu. W materiale i w komentarzach przewija się coś w stylu „pisze crudy więc po co mi to a wgl biznes tego nie chce i płacą mi za feature”, tutaj jest trochę nieporozumienie bo to że optymalizacja nie jest najważniejsza nie znaczy że można pisać jakkolwiek. Casey mówi tyle że warto wiedzieć jak działa cpu jak działa cachowanie jak kosztowne jest uderzanie do ramu itp. Kiedy programista jest tego świadomy to może czasem zamiast class użyć struct, zamiast list użyć array, czasem uprości jakieś obliczenia biznesowe żeby było mniej dzielenia itp. Sumarycznie ilość kodu i czasu jest taka sama ale wydajność zauważalnie lepsze. A zgodnie z zasadą 80/20 nie trzeba poświęcać kilku lat żeby studiować budowę pamięci żeby w tym samym czasie pisać wydajniejszy kod. No i też nie płacą nam za wydajniejszy kod o 30% ale chyba na tym polega rozwój że w podobnym czasie potrafimy napisać lepszy kod.

40 minuta - w wyniku badań Dunninga i Krugera nie było wniosku, że początkujący myślą, że to wszystko jest proste i wiedzą wszystko, tak jak pokazuje to popularny wykres. Prawdziwy wykres można znaleźć np na wikipedii en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect i pokazuje że początkujący rzeczywiście troche zawyżają swoje wyobrażenie o siebie a eksperci zaniżają... ale to nie jest tak ktoś słaby wyobraża sobie siebie jako geniusza. Wykres pokazuje bardziej, że uczeń mający szanse na maksymalnie 1 lub 2, myśli że ma szanse na 3, uczeń mający duże szanse na 5, akceptuje że może dostać 5-, a uczniowie którzy zazwyczaj dostają 3 i 4, tacy średniacy, będą troche zawyżać oczekiwane wyniki, ale mało.

Dlatego nigdy nikt nie był w stanie zachęcić mnie do tego edytora, a wszystkie zajęcia z c#/c++ na studiach i kursach sprawiały, że chciałem rozwalić monitor.

Zacząłem oglądać ten odcinek debugując Terraforma do Grafany. Wersja 10.4 ma Buga przy notification policy. Trzeba zaktualizować całą Grafanę do wersji 11.0.

Co do gamedevu to widać ostatnio bunt ludzi jeśli chodzi o kiepską optymalizację i niską jakość premierowych gier więc to nie jest tak że ludzie wolą mieć "szybko" dostarczoną wartość nawet kosztem innych rzeczy. Kto nie narzekał na slacka albo teamsy, które się zawieszają, wiadomości nie potrafią dochodzić i jeszcze wszystko koszmarnie muli i żre dużą ilość ramu? Wy prowadzicie dyskusje z perspektywy webdevu, a nie oprogramowania jako takiego. Webdev jest specyficzny, dużo problemów można "ukryć" chmurą i po prostu dobrymi serwerami. Natomiast zwykłe oprogramowanie użytkowe instalowane na komputerach ludzi to trochę inna para kaloszy. Bo kiepsko napisane oprogramowanie przyczynia się do postarzania sprzętu i generowania elektrośmieci ale też po prostu powoduje, że komfort użytkowania spada. Dlaczego ludzie lubią apple? Bo wszystko działa, jest całkiem wydajne i stabilne. Casey nie mówił o webdevie, dla webdevu rzeczywiście nie ma znaczenia optymalizacja algorytmiczna czy nawet pamięciowa bo wszystko można wrzucić na jakaś szybką chmurę z xeonami i nie wiem 64-128gb ramu na maszynie, problemy wydajnościowe można wyskalować horyzontalnie. Taniej jest kupić dobry sprzęt niż płacić specjalistom za dobrze zoptymalizowane oprogramowanie a w webdevie kluczowa jest szybkość działania usługi a nie jej wymagania sprzętowe. Co innego cała reszta; gry, aplikacje systemowe, systemy operacyjne, aplikacje użytkowe instalowane na urządzeniach, iot i tak dalej.

Bo nikt nie optymalizuje,tylko robi z klocków.Nie ma już nowego oprogramowania.Oprogramowanie jest pisane w C,C++,albo C#.Biznes chce mieć szybko,Nikt nie bawi się w przepisywanie głównych procedur w assemblerze,bo nikt za to nie zapłaci.

fajnie dla programistow byloby sie bawic z performancem, unsafe c#, assemblery etc ale skoro biznes nie da na to zgody (czyli nikt za to nie zaplaci) to nikomu sie nie oplaca poswiecac czasu na takie rzeczy, skoro moze przyjac dawke wiedzy ktora moze mu zapewnic benefity w pracy