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
Gdyby ludzie zawsze mieli rozumieć wszystko od podstaw, zanim wejdą w coś skomplikowanego, to żeby świat szedł do przodu to albo byśmy musieli żyć po 200 lat, albo byśmy dalej co najwyżej budowali kalkulatory.
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.
Z tego co wiem to Casey pisze w C, więc tam jest zdecydowanie więcej możliwości na ewentualną poprawe wydajności chociażby pod względem zarządzania pamięci. W aplikacjach webowych/biznesowych i tak przeważnie bottleneckiem jest baza danych, więc największy zwrot pod kątem wydajności by był z lepszej znajomości SQL/bazy danych.
Nie no zdecydowanie nie twierdzimy, że biznesówki == "nie musi działać szybko, byle była wartość" :D Myślę, że tutaj jednak sporo zależy od skali projektu oraz ilość ludzi, którzy nad nim pracują. Więcej osób to jednak często utrata pełnej kontroli nad tym co wpada na produkcję. Zdecydowanie powinniśmy pisać kod możliwe dobry jakościowo (choć często też clean code != fast code i wspominaliśmy o tym przy DDD trilemma) i celować w jego poprawę nawet zaczynając od tak małych rzeczy jak "boy scout rule". Pełna zgoda co do tego o czym napisałeś " 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. " Problem z naszych obserwacji jest taki, że szczególnie w dużych systemach problemy wydajnościowe zaczynają się dużo wyżej. A to ktoś zrobi Task.Result i zrobi sync-over-async co doprowadzi na IIS do thread-starvation, a to ktoś napisze zapytanie, które powoduje N+1 i rezultat pobiera się 30s itd. Takie problemy paradoksalnie dużo łatwiej wykryć i poprawić (bo często są customer-facing), a pozostawione stanowią realne problemy dla firm, które za swoje rozwiązania kasują słono :D My oczywiście komentujemy to z punktu web dev, który nijak się ma do innych odnóg programowania, gdzie często wydajność jest "first-level citizen". Czy w aplikacjach webowych tak jest? Ja śmiem wątpić, co nie znaczy, że jest mi z tym dobrze ;) /D
@@DevMentorsPL Też cięzko sie nie zgodzić, generalnie to kazdy mógłby wymienić jakiś kawałek systemu i powiedziec że jest ważny i kazdy bedzie miał racje. Problem który ja chciałem zaadresowac w komentarzu byl taki że programisci czestą usprawiedliwiaja ignorancje własnie zdaniem ze "wydajnosc nie jest kluczowa". A moim zdaniem to własnie nie oznacza ze mozna położyć lache na kod. Moim zdaniem to oznacza tyle że skoro optymalizacja nie jest na pierwszym miejscu to zamiast C moge sobie wybrać Jave, Pythona czy nawet JS i w technologi którą wybiorę i tak staram sie pisac najbardziej wydajny kod jaki moge. "Takie problemy paradoksalnie dużo łatwiej wykryć i poprawić...", "Czy w aplikacjach webowych tak jest? Ja śmiem wątpić, co nie znaczy, że jest mi z tym dobrze ;)" - absolutnie nie dyskutuje z priorytetami, bardziej z podejsciem do produktu który wytwarzamy. (pisze z perspektywy nerda który lubi programowanie i niestety osoby która gasi pozary wydajnosciowe w apkach webowych zeby było smieszniej) Czy jeśli bierzemy 150-200 zł/h to czy kod który piszemy moze miec tak trywialne błędy? "..dużo łatwiej wykryć i poprawić.." tylko po co? Czy nie powinnismy dazyć w zespole zeby nie było takiej potrzeby? (mówie tu o takich trywialnych problemach np. jak wyzej wspomniałeś n+1). "często też clean code != fast code" - paradoksalnie jak czasem musze cos poprawić to doprowadzenie kodu do clean code jest połową sukcesu :D
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.
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.
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.
Bardzo fajny temat i format. Co do osoby Caseya, to on w ogóle jest krytykiem podejścia Clean Code, że takie programowanie powoduje mocne obniżenie wydajności aplikacji. Mówiąc o złym kodzie, to chyba miał właśnie to na myśli. Z drugiej strony, brak czystego kodu jest powodem spowalniania prac na kodem, szczególnie jego rozwojem. To byłby ciekawy temat, może jakieś testy zrobicie? Warto by ten temat poruszyć i spróbować wyważyć co jest warte.
Halo halo, iPada Pro akurat mialem prawie 3 lata i uważam że to jest absolutne top1 tabletów. :D A do Macbooka Pro mi co raz bliżej, ASUS mnie wyleczył z eGPU i powoli z Windowsa 😅 /M
Dla mnie brak postępu w czasie odpowiedzi serwisów jest po prostu akceptowalny. Zeszliśmy do granicy gdzie nie jest to irytujące i that’s it o ile nie ma silnie uargumentowanego przypadku ze czasy powinny być mniejsze np transakcje giełdowe itd. Jesli nie narzeka na to pół świata tylko 3 osoby i nie powstaje konkurencja której główna propozycja wartości jest poprawa tego czasu to dla mnie problem nie istnieje. Zakładam się że jakby Microsoft zidentyfikował problem ze użytkownicy odchodzą ze względu na czas otworzenia programu to byłoby to poprawione w 3 miesiące. A tak to po co mamy palić zasoby na poprawienie czegoś o 10 sekund jak nie ma na to logicznego uzasadnienia
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…
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.
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.
Format super - czapki z głów.
Good one XDDD
Format jest świetny a pogadanki naprawdę wartościowe, brakowało mi takiego kanału jak wasz w polskim języku. Robicie świetną robotę :)
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
Pytanie czy ma to sens w ogóle, skoro meta oficjalnie ogłosiła, że pod koniec 2025 będą zwalniać programistów, bo AI radzi sobie już na tyle dobrze.
@@Distx87 xD
Gdyby ludzie zawsze mieli rozumieć wszystko od podstaw, zanim wejdą w coś skomplikowanego, to żeby świat szedł do przodu to albo byśmy musieli żyć po 200 lat, albo byśmy dalej co najwyżej budowali kalkulatory.
pozdro dla 200 letnich fizyków w takim razie
totalnie się niezgadzam.
@@paca3107 Masz do tego prawo :)
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.
Z tego co wiem to Casey pisze w C, więc tam jest zdecydowanie więcej możliwości na ewentualną poprawe wydajności chociażby pod względem zarządzania pamięci. W aplikacjach webowych/biznesowych i tak przeważnie bottleneckiem jest baza danych, więc największy zwrot pod kątem wydajności by był z lepszej znajomości SQL/bazy danych.
Nie no zdecydowanie nie twierdzimy, że biznesówki == "nie musi działać szybko, byle była wartość" :D
Myślę, że tutaj jednak sporo zależy od skali projektu oraz ilość ludzi, którzy nad nim pracują. Więcej osób to jednak często utrata pełnej kontroli nad tym co wpada na produkcję. Zdecydowanie powinniśmy pisać kod możliwe dobry jakościowo (choć często też clean code != fast code i wspominaliśmy o tym przy DDD trilemma) i celować w jego poprawę nawet zaczynając od tak małych rzeczy jak "boy scout rule".
Pełna zgoda co do tego o czym napisałeś " 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. "
Problem z naszych obserwacji jest taki, że szczególnie w dużych systemach problemy wydajnościowe zaczynają się dużo wyżej. A to ktoś zrobi Task.Result i zrobi sync-over-async co doprowadzi na IIS do thread-starvation, a to ktoś napisze zapytanie, które powoduje N+1 i rezultat pobiera się 30s itd. Takie problemy paradoksalnie dużo łatwiej wykryć i poprawić (bo często są customer-facing), a pozostawione stanowią realne problemy dla firm, które za swoje rozwiązania kasują słono :D
My oczywiście komentujemy to z punktu web dev, który nijak się ma do innych odnóg programowania, gdzie często wydajność jest "first-level citizen". Czy w aplikacjach webowych tak jest? Ja śmiem wątpić, co nie znaczy, że jest mi z tym dobrze ;)
/D
@@DevMentorsPL Też cięzko sie nie zgodzić, generalnie to kazdy mógłby wymienić jakiś kawałek systemu i powiedziec że jest ważny i kazdy bedzie miał racje. Problem który ja chciałem zaadresowac w komentarzu byl taki że programisci czestą usprawiedliwiaja ignorancje własnie zdaniem ze "wydajnosc nie jest kluczowa". A moim zdaniem to własnie nie oznacza ze mozna położyć lache na kod. Moim zdaniem to oznacza tyle że skoro optymalizacja nie jest na pierwszym miejscu to zamiast C moge sobie wybrać Jave, Pythona czy nawet JS i w technologi którą wybiorę i tak staram sie pisac najbardziej wydajny kod jaki moge.
"Takie problemy paradoksalnie dużo łatwiej wykryć i poprawić...", "Czy w aplikacjach webowych tak jest? Ja śmiem wątpić, co nie znaczy, że jest mi z tym dobrze ;)" - absolutnie nie dyskutuje z priorytetami, bardziej z podejsciem do produktu który wytwarzamy. (pisze z perspektywy nerda który lubi programowanie i niestety osoby która gasi pozary wydajnosciowe w apkach webowych zeby było smieszniej) Czy jeśli bierzemy 150-200 zł/h to czy kod który piszemy moze miec tak trywialne błędy? "..dużo łatwiej wykryć i poprawić.." tylko po co? Czy nie powinnismy dazyć w zespole zeby nie było takiej potrzeby? (mówie tu o takich trywialnych problemach np. jak wyzej wspomniałeś n+1).
"często też clean code != fast code" - paradoksalnie jak czasem musze cos poprawić to doprowadzenie kodu do clean code jest połową sukcesu :D
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.
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.
czapka LP, masz u mnie +1000 do respektu :D
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.
Chyba pomyliliście Hip-hop z IT
Sry ziom, następnym razem będzie koszula w krate, flanelowa.
Bardzo fajny temat i format. Co do osoby Caseya, to on w ogóle jest krytykiem podejścia Clean Code, że takie programowanie powoduje mocne obniżenie wydajności aplikacji. Mówiąc o złym kodzie, to chyba miał właśnie to na myśli. Z drugiej strony, brak czystego kodu jest powodem spowalniania prac na kodem, szczególnie jego rozwojem. To byłby ciekawy temat, może jakieś testy zrobicie? Warto by ten temat poruszyć i spróbować wyważyć co jest warte.
Pierwsze minuty i szok co tam przed Michałem stoi Zastanawia mnie jak chodzi Windows na iPad 😃
Halo halo, iPada Pro akurat mialem prawie 3 lata i uważam że to jest absolutne top1 tabletów. :D
A do Macbooka Pro mi co raz bliżej, ASUS mnie wyleczył z eGPU i powoli z Windowsa 😅
/M
Dla mnie brak postępu w czasie odpowiedzi serwisów jest po prostu akceptowalny. Zeszliśmy do granicy gdzie nie jest to irytujące i that’s it o ile nie ma silnie uargumentowanego przypadku ze czasy powinny być mniejsze np transakcje giełdowe itd. Jesli nie narzeka na to pół świata tylko 3 osoby i nie powstaje konkurencja której główna propozycja wartości jest poprawa tego czasu to dla mnie problem nie istnieje. Zakładam się że jakby Microsoft zidentyfikował problem ze użytkownicy odchodzą ze względu na czas otworzenia programu to byłoby to poprawione w 3 miesiące. A tak to po co mamy palić zasoby na poprawienie czegoś o 10 sekund jak nie ma na to logicznego uzasadnienia
Tym bardziej że nie na tym Microsoft zarabia
Do 2010 VS był pisany w C++,
teraz to c#?
Dopóki biznes nie chce za takie rzeczy płacić to nikogo to nie interesuje :D
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…
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.
Файні шапки :)
@DevMentors w jakim hackathonie braliście udział?
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.