(Nie)doskonałe kursy Mirosława Zelenta (recenzja)

Question

TLDR: http://szymonsiarkiewicz.pl/artykuly/testy-i-recenzje/kursy-miroslawa-zelenta/

Hej, chciałbym podzielić się z Wami artem w którym chciałem pokazać, że Kursy MZ -wbrew temu co myśli spora część pasjonatów - nie są doskonale.

Przed lekturą prosiłbym o dokładne przeczytanie arta, tak żeby nie robić niepotrzebnie (kolejnej) awantury z obrzucaniem się błotem.

Zapraszam do lektury i do (kulturalnego) wyrażenia swojej opinii / komentarza:

http://szymonsiarkiewicz.pl/artykuly/testy-i-recenzje/kursy-miroslawa-zelenta/

Comments

Wyczuwam kolejną burzę. Obym się mylił.

---

Cóż, mi się wydaje że wykazalem też sporo pozytywów. Raczej każdy ze zdrowym podejściem po prostu zastanowi się nad tym co nspisale i straci jakiś ciekawy komentarz.

Shit-stormu też nie chcę, ale myślę że nie powstanie ;)

---

Ja myślę, że większość osób na tym forum mogłaby zostać tak samo pouczona przez senior deweloperów. O ile programiści się dzielą wiedzą, to są to materiały takie sobie albo płatne. Mirek się przebił i przekazywania wiedzy mogą się od niego uczyć najlepsi.

---

No cóż, jeszcze się taki nie narodził, ci by każdemu dogodził!
Zgadzam się z opinią, że kursy M. Zelenta nie są doskonałe, ale na pewno są warte uwagi i godne polecenia, zwłaszcza dla osób zaczynających przygodę z programowaniem.
I zgadzam się z opinią, że przekazywania wiedzy od M. Zelenta mogą i powinni wręcz się uczyć najlepsi.

---

Jasne, o ile przeczytaliscie arta to zobaczyliscie że napisałem o nim jako "zachęcaczu" do programowania ;)

---

Miałem na myśli programowanie w sensie ogólnym, a nie tylko C++ i przeczytałem uważnie arta

---

Temat byl już wielokrotnie poruszany.

---

Zgadza się, ale nigdy w pełni na spokojnie. Bez chęci ukazania, że są rzeczy zrobione dobrze i źle ;)

Myślę że takie coś jest fajnie podlinkowac nowym pasjonatom na otwarcie oczu :)

Dla części nie jest to nic nowego, nie jest to także forma prowadząca do shit-sztormu, na którą pewnie część osób liczyło widząc tytuł.

Jest to kulturalna rozmowa, otwarte zwrócenie uwagi na pewne rzeczy, które warto pokazać. Jak widać po komentarzach poniżej udało nam się to osiągnąć w tym wpisie ;) I do tego dążyłem.

Dzięki wszystkim za kulturalny feedback :)

Answer 1

O, dzięki za podesłanie linka :) Wpis fajny, napisany na poziomie i z kulturą - w dobie bardzo agresywnych "młodych gniewnych", którzy obrażają bez pardonu taka krytyka jest jak oddech świeżym powietrzem (wartościowej krytyki jest bardzo mało). Co do merytoryki nie będę się wypowiadał, bo o tym wszystkim już mówiłem wielokrotnie - zwłaszcza o właściwym (w moim mniemaniu) momencie wprowadzenia tagów HTML5 w cykl nauki HTML. Osobiście jestem zdania że metoda od ogółu do szczegółu (od rozwiązań starszych z ich implementacją do nowych również z implementacją = ewolucja rozwiązań) jest lepsza aniżeli od szczegółu do ogółu (implementacja najnowszej techniki z wiedzą o tym jak było kiedyś, ale bez zastosowania i implementacji). Ale to jest kwestia stylu nauczania - ilu dydaktyków, tyle metod. Ponadto jest to cecha osobowa - jako ludzie wykazujemy inne konstrukcje mentalne (mamy preferencję ogół vs. szczegół, tak jak mamy osądzanie vs. obserwowanie, wzrokowców i kinestyków, intuicję vs. percepcję etc). Rozmowa na temat nauczania musi wyjść na grunt empatii wobec odmiennych typów, tylko wtedy ma sens. A jednocześnie wyboru metody wstępującej lub zstępującej i tak trzeba w kursie dokonać. Moje kursy zawsze będą bliższe osobom preferującym metodę od ogółu do szczegółu, aniżeli osobom o stylu od szczegółu do ogółu. Tak samo sprawa ma się z attention spanem, czyli długością odcinków - dla jednego będą za krótkie, dla innego przesadnie długie. Nikt nigdy nie zadowoli wszystkich odbiorców, jesteśmy zbyt różnorodni jako ludzie. Nikt też nie jest w stanie tworzyć rzeczy idealnych. Pozdrawiam, dzięki za głos w dyskusji! :)

Comments

Obawiam się że nastąpiło pewne nieporozumienie.

Ja nie mówię ogólnie o sposobie nauczania: ogół-szczegół i vice versa, bo to Pańska sprawa jak Pan naucza (o czym też Pan wspomniał u siebie w komentarzu). Tylko o tym, czy należy przedstawić "starą" wiedzę jako aktualną.

Tutaj zabrakło takiego dosadnego stwierdzenia: "teraz pokaże wam to i to, ale nie używajcie tego w produkcyjnym kodzie" - to zdanie powinno być powtarzane często i dobitnie. Niestety nie zostalo to wykonane odpowiednioe, co potwierdzają przykłady na forum, które namnażają się każdego dnia - z tym właśnie się nie zgadzam.

Co do długości odcinków to jasne - jak kto lubi, chociaż istnieje pewna teoria "checkpointow, która pokazuje że lepiej jest robić więcej naturalnych przerw (stosowana także w grach i literaturze). Ale tu nie będę się upierał, jeżeli tak jest panu lepiej, to spoko ;)

Btw dzięki za komentarz, liczę ze moje "review" pozwoli na chociaż w minimalnym stopniu ulepszenie Pańskich kursów ;)

---

Ja nie mówię ogólnie o sposobie nauczania: ogół-szczegół i vice versa, bo to Pańska sprawa jak Pan naucza (o czym też Pan wspomniał u siebie w komentarzu). Tylko o tym, czy należy przedstawić "starą" wiedzę jako aktualną.

Wczytaj się w ten fragment mojej wypowiedzi, celowo udzieliłem szczegółowych wyjaśnień w nawiasach:

Osobiście jestem zdania że metoda od ogółu do szczegółu (od rozwiązań starszych z ich implementacją do nowych również z implementacją = ewolucja rozwiązań) jest lepsza aniżeli od szczegółu do ogółu (implementacja najnowszej techniki z wiedzą o tym jak było kiedyś, ale bez zastosowania i implementacji).

Te właśnie sposoby podejścia do starszych / nowych technik miałem na myśli. Imho taksonomicznie więcej poziomów zostanie poruszonych w metodzie ewolucji rozwiązań (za każdym razem wiedza, zrozumienie, zastosowanie, analiza, synteza a nawet ocenianie) dla starszych metod, a w podejściu wstępującym dla starszych technik poruszymy tylko wiedzę i przy uważnej lekturze zrozumienie (już nie wyżej, bo nie stosujemy starej metody). Mniej więcej o to mi chodzi, jeśli mowa o przewadze podejścia zaczynania od starszych, ogólnych technik (jak atrybut onlick w JS, divy i nie używanie tabel w HTML itd.).

Tutaj zabrakło takiego dosadnego stwierdzenia: "teraz pokaże wam to i to, ale nie używajcie tego w produkcyjnym kodzie" - to zdanie powinno być powtarzane często i dobitnie. Niestety nie zostalo to wykonane odpowiednioe, co potwierdzają przykłady na forum, które namnażają się każdego dnia - z tym właśnie się nie zgadzam.

Wiem co masz na myśli, ale wg mnie za bardzo tutaj patrzymy na to z perspektywy pojedynczego odcinka / kodu źródłowego, a nie całego kursu (zbyt wąski promień widzenia). Po np. odcinku 1, 2, 3 czy 4 kursu HTML owszem ktoś pisze struktury tylko na divach, ale po odcinku 5 już nie, bo poznał w nim semantykę. A zaletą podejścia zstępującego jest to, że po tym 5-tym odcinku ma w głowie i "w palcach" nie tylko tę semantykę, ale także wszystkie etapy wcześniejsze: od nieużywania tabel, przez float:left i display:inline-block. Wg mnie są to etapy chronologicznie następujące po sobie i one stworzą bardziej kompletnego i świadomego twórcę struktur html. Nie ma tu jeszcze RWD, ale na to też przyjdzie pora w swoim czasie, (tak jak przyszła na semantykę) - nie da się wszystkiego wprowadzić tak od razu. 

Oczywiście to tylko mój punkt widzenia, ale taki styl nauczania osobiście uważam za najlepszy. Nie mam też problemu z tym, że ktoś może mieć styl odmienny i tak uczyć, a metodę zstępującą uważać za gorszą. Rozumiem też, że to moje podejście wymaga czasu, a odcinki wychodzą nie tak często jak by było przy tym podejściu wskazane. Zwróćmy jednak uwagę, że porządne, wręcz łopatologiczne przeprowadzenie kogoś od tabel do RWD wymaga nielada nakładów czasowych (fakt, iż po odcinku zaledwie 5-tym jesteśmy już po semantyce jest i tak tempem super szybkim). 

Mało ludzi natomiast stara się w ogóle zrozumieć tę metodę nauczania, najlepszym przykładem są ludzie bezpardonowo krytykujący odcinki po ukazaniu się epizodu 2-go czy 3-go kursu (totalne ignorowanie całokształtu projektu kursu). Na filmach często pokazuję etap na którym się znajdujemy, np: https://youtu.be/cjhfsqsS24U?t=21m40s ale to nigdy nie będzie tak, że pytań nie będą zadawać młodzi ludzie na bardzo wczesnym etapie kursu. 

Co do checkpointów to zdecydowanie racja, stąd właśnie (dla podtrzymania atencji) różne humorystyczne wstawki obniżające napięcie, zwłaszcza w ponad godzinnych produkcjach. Oczywiście ludzie często również i ten zabieg odczytają negatywnie, na zasadzie "gadasz o jakichś pierdołach, marnujesz mój czas, po co te dyrdymały". To ja tu śpiewam "Życie jest nowelą", albo opowiadam jak się w tańcu robi "pudełeczko" :) a i tak zawsze ktoś się znajdzie komu to nie przypasuje - zwykła rzecz. 

Btw dzięki za komentarz, liczę ze moje "review" pozwoli na chociaż w minimalnym stopniu ulepszenie Pańskich kursów ;)

Pewnie! Zawsze lubię poczytać taki feedback, żeby wyjść z własnych butów i wczuć się w punkt widzenia innej osoby. Autor nigdy nie ma świeżego spojrzenia na swoje dzieło. Dzięki jeszcze raz za artykuł, mam nadzieję że moje wyjaśnienia nie są postrzegane jako postawa "mam zawsze rację, jestem idealny", tylko jako wyjaśnienia mające na celu pokazać mój punkt widzenia (często perfekcjonista będzie to na mnie projektował, patrząc na moje słowa przez taki filtr). Twój artykuł fajnie pokazuje, że można mieć inny punkt widzenia, nie zgadzać się z moją metodą nauczania, ale zachować się jednocześnie jak dorosły facet, będąc obiektywnym i po prostu przedstawiając swój punkt widzenia na zagadnienie. Zwróciłem też szczególną uwagę na różne niuanse warsztatu, o których wspomniałeś w artykule. Fajnie się dyskutowało, pozdrawiam!

---

Chciałbym zauważyć, że nawet jeśli przyjmiemy założenie, słuszne jednocześnie, że dobrze jest uczyć się od ogółu do szczegółu (gdyż jest to dość naturalne dla sposobu nauczania człowieka), to wcale nie musi oznaczać, że ogółem ma być recz, technika czy technologia używana kiedyś.

Gdyby tak było, to dajmy na to - uczenie się prowadzenia samochodu musiałoby brać pod uwagę to, że kiedyś każdy samochód był napędzany korbą, lub też musielibyśmy na wykładach słuchać o tym dlaczego mówimy dziś o koniach mechanicznych a nie, na przykład, osłach mechanicznych.

Ogółem zaś może być przykładowy program, który wraz z rozwojem wiedzy jest rozwijany - co jest zgodne ze wszelkimi najnowocześniejszymi metodykami programowania. Najpierw próbujemy zająć się programem do obsługi bankomatu. Rozwijamy go z czasem dodając coraz to więcej rozszerzeń. Wtedy projektem, który realizujemy jest sam program poprzez programowanie, a nie wyłącznie programowanie.

Oczywiście w pewnym stopniu rozumiem, że idea tychże kursów w trakcie ich powstawania została przyjęta na taką, a sam ucząc się programowania robiłem to w zupełnie inny sposób niż tu zalecany. No, może nie zupełnie - bo sam uczyłem się od ogółu do szczegółu. Jednak ta nauka polegała na rozwijaniu dwu lub trzech projektów na które miałem pomysł. Dzięki temu nauczyłem się retrospekcji, która w programowaniu jest równie ważna - w końcu moje błędy rzutują na przyszłość, więc warto zrobić krok w tył by pójść dwa w przód. Stąd też ciągła refaktoryzacja obecna w moim życiu zawodowym (ciągła, czyli po odpowiednio i terminowo dostarczonym oprogramowaniu należy przysiąść i poświęcić czas na dopieszczenie cuda).

---

metoda od ogółu do szczegółu (od rozwiązań starszych z ich implementacją do nowych również z implementacją = ewolucja rozwiązań)

Nigdzie indziej nie widziałem takiej definicji "od ogółu do szczegółu". Zazwyczaj to po prostu oznacza "łagodna ścieżka trudności pozwalająca szybko zacząć działać, nie atakująca kolumną definicji które przydadzą się może kiedyś". Tutaj (wnioskując też po późniejszej odpowiedzi) wygląda to bardziej jak artystyczny synonim "od łatwego do skomplikowanego" (mam nadzieję, że nie uprościłem za bardzo - ale jestem przekonany, że docelowa intencja jest właśnie taka). Rzecz w tym, że klasyfikacja tego, co jest łatwe, a co skomplikowane nie jest sztywna - kreuje ją sam nauczyciel.

Na przykład: odrobinę niżej inna osoba też wspomniała o metodzie "od ogółu do szczegółu" i jako "szczegół" dała przykład "dlaczego nie używać zmiennych globalnych". Tymczasem równie dobrze można było poprowadzić naukę trochę inaczej - wystarczy o nich nie wspominać. Gdyby pierwszy (i każdy kolejny) program ze zmiennymi wyglądał od razu tak:

int main() {
  string tekst;
  cin >> tekst;
  cout << "powiedziales " << tekst;
}

Wtedy magicznie sama wiedza o zmiennych globalnych stałaby się "skomplikowanym specjalistycznym szczegółem" . Oczywiście też upraszczam - prędzej czy później trzeba o nich wspomnieć, choćby po to żeby wyjaśnić ludziom którzy przypadkiem zrobią zmienne globalne zamiast lokalnych, czemu ich kod wciąż działa :) . Natomiast jestem mocno przekonany, że takim żonglowaniem uczonymi tematami można uczynić dobre praktyki i współczesne ficzery języków "ogólnymi", a starsze/brzydsze "szczególnymi".

---

Do tego co powiedział adrian odnośnie zmiennych globalnych, chcę jedynie dopowiedzieć że taki mechanizm istnieje w kursie cpp0x.

Tzn nie mówi się o nich przez jakiś czas, później coś wspomina w stylu "są, ale zrozumienie kiedy można ich poprawnie użyć wykracza poza aktualny poziom nauki - póki co ich nie używaj, ale wiedz że coś takiego jest" i dopiero po jakimś czasie - gdy cała wiedza potrzebna do pełnego zrozumienia poprawnego ich użycia zostanie już przedstawiona - następuje oficjalne wprowadzenie zmiennych globalnych.

---

Gdyby tak było, to dajmy na to - uczenie się prowadzenia samochodu musiałoby brać pod uwagę to, że kiedyś każdy samochód był napędzany korbą, lub też musielibyśmy na wykładach słuchać o tym dlaczego mówimy dziś o koniach mechanicznych a nie, na przykład, osłach mechanicznych.

To jest mocno przejaskrawione porównanie i moim zdaniem nieadekwatne. Nieznajomość tego jak się kręci korbą nie wpłynie na umiejętność jazdy samochodem. Wiedza (i praktyka) jak np. ułożyć dwa divy obok siebie float leftem czy inline-blockiem to w tym porównaniu raczej umiejętność zmiany biegów, czy obsługi sprzęgła - bez tego ciężko będzie we front-endzie w ogóle gdzieś "pojechać". I łatwiej to opanować w praktyce niż w teorii, a szczególnie warto przepracować w uproszczonych warunkach placu manewrowego gdzie nie ma tak złożonej sytuacji jak na drodze i tylu decyzji, które trzeba podjąć na bazie doświadczenia. Używanie porównania do "korby" czy "osłów mechanicznych" (serio?) kłoci się z moim zdrowym rozsądkiem, strasznie w mojej opinii to przejaskrawiłeś.

Ogółem zaś może być przykładowy program, który wraz z rozwojem wiedzy jest rozwijany - co jest zgodne ze wszelkimi najnowocześniejszymi metodykami programowania. Najpierw próbujemy zająć się programem do obsługi bankomatu. Rozwijamy go z czasem dodając coraz to więcej rozszerzeń. Wtedy projektem, który realizujemy jest sam program poprzez programowanie, a nie wyłącznie programowanie. 

Oczywiście w pewnym stopniu rozumiem, że idea tychże kursów w trakcie ich powstawania została przyjęta na taką, a sam ucząc się programowania robiłem to w zupełnie inny sposób niż tu zalecany. No, może nie zupełnie - bo sam uczyłem się od ogółu do szczegółu. Jednak ta nauka polegała na rozwijaniu dwu lub trzech projektów na które miałem pomysł. Dzięki temu nauczyłem się retrospekcji, która w programowaniu jest równie ważna - w końcu moje błędy rzutują na przyszłość, więc warto zrobić krok w tył by pójść dwa w przód. Stąd też ciągła refaktoryzacja obecna w moim życiu zawodowym (ciągła, czyli po odpowiednio i terminowo dostarczonym oprogramowaniu należy przysiąść i poświęcić czas na dopieszczenie cuda).

Piękna idea, ale programowanie zawsze ma naturę optymalizacji, a rozwiązania ewoluują (a już zwłaszcza w webówce). Sam fakt stworzenia kursu wymusza na Tobie decyzję jak to zrealizować (podkreślam - mowa o kursie, a nie dokumentacji gdzie piszesz po prostu reference).

Jeśli pokażesz technikę najnowszą, to powinieneś przynajmniej pokazać rozwiązania wcześniejsze i wciąż spotykane, bo inaczej stworzysz niekompletny kurs. Siłą rzeczy więc wybrałeś metodę od szczegółu do ogółu, a jej wadą będzie tylko "wiedzowe" opanowanie przez kursanta aktualnego stanu ewolucji standardów (znamy szczegółowo obecnie stosowane rozwiązanie, o innych wiemy "ze słyszenia", bo nie z praktyki - nie było ich implementacji). Sporym ryzykiem jest tutaj wytworzenie u kursanta mindsetu nie opartego na pełnym zrozumieniu ewolucji i stanu webówki oraz myśleniu technicznym. Metoda ta posiada także dużo wyższy próg wejścia, bo wyjaśnienia "backwords" są dużo mniej przyswajalne, aniżeli wyjaśnienia "forward", które "rozrastają" się z czasem i doświadczeniem już zaimplementowanych, starszych technik. Metoda świetna do tworzenia kursów bardziej zaawansowanych, dla osób które "mają już bazę", gorsza dla początkujących.

Jeśli zaś pokażesz technikę starszą, to powinieneś zadbać o to, żeby koniecznie doprowadzić kogoś w kursie do rozwiązań aktualnych, bo inaczej stworzysz niekompletny kurs. Siłą rzeczy więc wybrałeś metodę od ogółu do szczegółu, a jej wadą będzie tworzenie przez kursanta kodów, które współcześnie mogą być uważane jedynie jako lekcja z fundamentów i tego co było kiedyś. Sporym ryzykiem jest tutaj wytworzenie u kursanta mindsetu, który zachłyśnie się "fundamentalną" wiedzą i nie przejdzie całej drogi, ergo nie osiągnie pełnego zrozumienia ewolucji i stanu webówki, będzie miał jedynie w miarę rozwinięte myślenie techniczne. Metoda ta posiada także dużo niższy próg wejścia, bo wyjaśnienia "forward", które "rozrastają" się z czasem i doświadczeniem już zaimplementowanych, starszych technik są dla wielu osób naturalne. Dużą zaletą jest też głębia zrozumienia dziedziny, bo nie pomijamy implementacji żadnej wciąż stosowanej techniki. Metoda świetna dla początkujących, gorsza dla osób które "mają już bazę".

Osobiście jestem po prostu zwolennikiem metody drugiej (zwłaszcza biorąc pod uwagę "target" ludzi do których tutoriale są kierowane), natomiast tworzenie jakiegokolwiek kursu zawsze zmusza do licznych wyborów - ilu ludzi tyle punktów widzenia na każdy możliwy wybór - kiedy wprowadzić w kursie to czy tamto, czy powiedzieć o tym i nauczyć realizować, czy jednak tylko wstępująco wspomnieć - takich decyzji jest mnóstwo.

Smutne jest jedynie, kiedy jakiś człowiek analizuje jeden z takich licznych wyborów i (ponieważ w tym punkcie podjąłby inny wybór niż twórca, tzn. uważa że realizując to inaczej byłoby to lepsze) przekreśla sens absolutnie wszystkiego co autor przedstawił. A nawet miesza jego osobę z błotem, kierując jakieś "wypokowe" inwektywy w jego stronę. To jest tak naprawdę mega nie fair, ale jak mówię rzadko kto tworzy krytykę na poziomie. Czasami też jako ludzie mamy tendencję do posiadania przeświadczenia, że nasze cechy osobowościowe są uniwersalne (tzn. jeśli ktoś jest wzrokowcem, to ma "bias" na taki punkt widzenia, albo lubi iść od szczegółu do ogółu, albo woli intuicję a nie percepcję itd.). 

Oczywiście nie mówię tu absolutnie o Tobie, tylko ogólnie o jakości wypowiedzi w sieci. Najczęściej ludzie ograniczają się do stwierdzeń w stylu "te dwie linie sprawiają, że tego kursu nie polecam...", "tutaj powinno się zrobić to wcześniej, więc to jest daremne...", "Jak można to pokazać tak, uważam że jako nauczyciel... " etc. Sami wydają wówczas świadectwo o braku głębi swojej analizy. Sprawy nie ułatwia także sukces kanału i kursów - ludzie tego nie przyznają, ale ego działa i zawsze osobę na świeczniku lepiej jest skrytykować, bo to daje więcej boosta do ego no i moje nazwisko może pomóc np. wypozycjonować wpis, a nawet cały serwis w google. Dlatego kiedy widzę słowa osoby, która przynajmniej zainteresowana jest dyskusją, a nie osądzaniem, to aż się miło robi w porównaniu do zwyczajowej, słabej krytyki.

Dziękuję za podzielenie się tym, jak ty to widziałeś w swojej nauce, zawsze pytam o to ludzi, których uczę na żywo - zbieranie takich doświadczeń bardzo pomaga rozwijać warsztat. Ponownie - mam nadzieję że moje wyjaśnienia nie są postrzegane jako postawa "mam zawsze rację, jestem idealny", tylko jako wyjaśnienia mające na celu pokazać mój punkt widzenia (często perfekcjonista będzie to na mnie projektował, patrząc na moje słowa przez taki filtr). Dziękuję za głos w dyskusji, pozdrawiam!

---

Musiałem kilka razy przeczytać to, co napisałeś. 

Oczywiście, że przejaskrawione. Jednak to tylko abstrakcyjny przykład, który możliwe, że nie objął istoty tego, co chciałem przekazać. 

Tezą było dokładnie to: 

Chciałbym zauważyć, że nawet jeśli przyjmiemy założenie, słuszne jednocześnie, że dobrze jest uczyć się od ogółu do szczegółu (gdyż jest to dość naturalne dla sposobu nauczania człowieka), to wcale nie musi oznaczać, że ogółem ma być rzecz, technika czy technologia używana kiedyś. 

 Kod pisany kiedyś - dajmy na to w PHP - dziś, często, już nie jest tylko nieaktualny, ale uważany za błędny. Część rozwiązań które były zaimplementowane w PHP 4 do PHP5.4 jest również niedziałająca. Teraz dochodzimy do momentu, gdy chcemy ukazać kurs kompletny. Jak w takim razie na nowej wersji PHP pokazać działające rzeczy, które są już z niej usunięte? Jakie można dostrzec w tym plusy poza poświęceniem dodatkowego czasu na wyjaśnienie ich działania kiedyś gdyż uczeń nie odtworzy danej sytuacji. 

To właśnie to jest problematyczne i sprawia tyle gwaru dookoła kursów. Bo trudno jest komukolwiek zrozumieć, z jakiego powodu w kursie pojawiają się, niestety często, rażące błędy będące zaszłością. Swoją drogą przez właśnie te błędne rozwiązania język ten (PHP) najwięcej ucierpiał w przeszłości. Stąd też taka burzliwa dyskusja budzi się zwykle przy okazji nowych odcinków. 

Widząc sukces tego projektu ludzie dostrzegają również jego wady. Możliwe, że powstanie on jako kompletna całość, ale trwa to niewspółmiernie długo do przyrostu uczniów, którzy zatrzymują się w pewnym niewypełnionym jeszcze miejscu. Rozumiem małe kroczki, swojego czasu przestudiowałem kilkanaście źródeł odnośnie taksonomii blooma i dalej nie jestem przekonany do tego, by ta metodologia wymuszała na nauczycielu podejścia takiego, w którym uczy od najstarszych aspektów w celu zrozumienia istoty pewnych zachowań które są obecne dziś. 

To, jak ja rozumiem naukę programowania od ogółu do szczegółu, to nauczenie się fundamentów języka programowania: operatorów, zmiennych, funkcji, typów zmiennych, warunków logicznych, pętli. To są, w moim przekonaniu ogólniki, które pozwolą mi stworzyć swoje oprogramowanie - takie, które będzie moim pierwszym. 

Mogę tworzyć program, który sobie "zaprojektuję" w głowie lub na kartce - chcę by robił to i tamto. Ale jeszcze nie potrafię, więc idę do zapisywania i wyświetlania zmiennych. Dowiaduję się, że zmienne mają swoje typy. Następnie chcę zrobić aplikację "czajnik" która przy 99 stopniach celsjusza zmienni "pstryczek" na wyłączony. Więc wykorzystuję instrukcje warunkowe. Piszę tak kilka/kilkanaście aplikacji które zawierają w sobie coraz więcej tychże skomplikowanych elementów. Chciałbym stworzyć już aplikację większą, więc musze dowiedzieć się o tym jak przechwytywać błędy i mówić użytkownikowi żeby coś poprawił. 

Gdybym na samym początku poznał operator wygłuszenia, osiągnąłbym następujące efekty:

• nie wiedziałbym, że tworzę kod, który robi błędy
• przez co czułbym sie na tyle dobry, że miałbym chęć na tworzenie kolejnych programów
• wyrobiłbym sobie nawyk stawiania operatora "@" w wielu sytuacjach, w których niekoniecznie powinien się pojawić. Na przykład przy operacjach na bazach danych. 

W chwili, gdy pojawi się temat obsługi wyjątków będę się zastanawiać, z jakiego powodu mam rezygnować z tej małpy, na rzecz kilku dodatkowych linijek, które zatrzymują mi zupełnie aplikację. 

To nie jest wyimaginowane i przejaskrawione, bo tak właśnie sam robiłem gdy najpierw nauczyłem się PHP w gimnazjum, gdzie "@" była wszechobecna w tych czasach, a powróciłem do programowania w późniejszym wieku studyjnym. Nawyk ten chodził za mną dość długo i wiem, że to nie jest takie proste, by pozbyć się złych nawyków. Jest to możliwe, ale wyobraźmy sobie nagle zacząć myć zęby drugą ręką. 

To wydaje się być ogółem w holistycznym podejściu do tego kursu. Ale na linii czasu wydaje się być czymś zupełnie zbędnym na początkowym etapie nauki. Człowiek nie przyzwyczai się do tego jak wyglądają błędy w PHP więc później nie będzie równie czujny. Dużo lepiej, znów moim zdaniem, wyglądałoby to tak, że do pewnego momentu nie wspominamy o tym operatorze. Dopiero przy omawianiu wyjątków wspomniałbym, że kiedyś korzystano z "@" do wygłuszania błędów, jednak spotkało się to z ogniem krytyki oraz wieloma problemami, które znacząco spowalniały proces wykrywania błędów w większych systemach, a nawet w prostych mniejszych stronach. Jednocześnie zaznaczyłbym, że użycie tego operatora jest mile widziane często przy instrukcjach warunkowych sprawdzających istnienie pliku czy katalogu. 
Z mojego punktu widzenia taki sposób przekazania wiedzy dość kontrowersyjnej byłby najbardziej znośny dla wszystkich zainteresowanych stron. Możliwe, że źle mi się wydaje. Na pewno ja sam chciałbym być w taki sposób nauczony. Taki kurs byłby kompletny, bo zawiera stare rozwiązanie i nowoczesne. Kursant wie i rozumie wady i zalety obu rozwiązań i jest świadomy tego, że ten operator ma swoje zastosowanie, ale w bardzo wąskim zakresie, a ludzie doświadczeni zawodowo nie mają argumentów by w jakikolwiek sposób oczernić taki sposób przekazania wiedzy. Oczywiście pomijając malkontentów. 

Gdybym ja tworzył kurs, który miałby być dla młodych ludzi niemających nic wspólnego z programowaniem to właśnie jedyną rzeczą jaką bym założył na początku, że uczyłbym "potajemnie" w taki sposób, aby kod był zgodny z dzisiejszymi standardami - zachowałby odpowiednie formatowanie, odpowiednio bym nazywał metody i zmienne. Starałbym się pisać bez zaszłości danego języka, które budziłyby kontrowersje. A wszystko to po to, by już od samego początku po cichu wyrabiać pewne dobre nawyki. A w przypadku omawiania konkretnego zagadnienia dopiero wtedy bym mówił o tym dlaczego robi się w ten a nie w inny sposób i skąd wywodzi się w ogóle ten pomysł. 

Tak samo jak zawsze gdy mówi się o programowaniu w stylu SOLID, to zawsze mówię, że wcześniej był GRASP i że na pewnych podstawach prac Bertranda Meyera powstały dzisiejsze nowoczesne standardy. Zwykle odwołuje się do jego argumentów, poprzez argumenty Uncle Boba, które są fasadą na starsze pomysły z nowinkami technologicznymi. To ma sens, bo to wszystko wyjaśnia dlaczego w ogóle powstało programowanie obiektowe, lub dlaczego zostało rozpopularyzowane, i skąd później powstały i standardy programowania i wzorce projektowe. to wszystko miało korzenie wcześniej i warto o tym wiedzieć. 
Jednak nie uważam za wartościowe i konieczne do pełni zrozumienia pokazanie ukrywania błędów w sytuacjach w których powinno się je przechwytywać. Równie dobrze można byłoby zupełnie pominąć takie kawałki kodu i zachować je na odpowiedni czas, gdy przyjdzie sytuacja, że rzeczywiście będzie się trzeba jakimś błędem zająć. 

 

Podsumowując

Nie rozumiem do końca samego podejścia w tym kursie, że kod ewidentnie błędny musi być koniecznie pokazany. Rozumiem, że wynika to z chęci stworzenia opus magnum, którym będzie kompletny kurs PHP. Jednak nie widzę tu wartości dodanej która mogłaby mnie przekonać do tego, że pokazanie kodu błędnego i jego omówienie w sposób niekompletny - bo przecież nie wspominasz o tym, że dziś odchodzi się od takich rozwiązań i nie mówisz kiedy rzeczywiście dobrze jest postawić tę małpę, tylko stawiasz ją w krytycznym miejscu w programie, które właśnie powinno pokazać że coś jest nie tak - miałoby sens w tym kursie. Taki kod powinien poczekać do momentu w którym będziesz omawiać sytuacje wyjątkowe, obsługę błędów itp. Wtedy mógłbyś jasno powiedzieć, że kiedyś robiło się tak, a dziś to wykorzystuje się w nielicznych sytuacjach, ale zawsze niesie to za sobą pewne wady i zalety których trzeba być świadomym. 
 

Ja uczę się obrazami, i gdy patrzyłem na te lekcje w których pokazywałeś wygłuszanie błędów zamiast ich obsługi czułem się jakbyś uczył dzieci jeździć rowerem ale z wykorzystaniem tylko jednej nogi. Jasne - znów przejaskrawiam, ale to jest jakaś reprezentacja tego co odczuwam. To jest również niekompletne w tym sensie, że człowiek po obejrzeniu tego kursu nie wie czemu coś nie działa i nie wie że aby dowiedzieć się trzeba usunąć wszystkie małpy w kodzie i dodać raportowanie błędów. Aczkolwiek chyba w ostatnim odcinku mówiłeś o tym - mogę już nie pamiętać. 

Trudno mi oceniać to wszystko w kontekście tak małej liczby filmów odnośnie PHP. Jednak mógłbym uznać kurs C++ za kompletny i wiem, że do ostatnich odcinków odnośnie C++ zabrakło wielu informacji o dobrych i złych praktykach w tymże języku - co pozwala mi myśleć, że zabraknie tych informacji również w kursie PHP. 

Dlatego też cieszę się, że zgodziłeś się na to, by programiści którzy tu najwięcej krzyczą na jakość kodu w kursach mogli przejrzeć przed publikacją Twój kod i uzupełnić go o pewne uwagi jeśli takie by były. To duży krok w przód, bo przecież ludziom wcale nie zależy na bezpodstawnym hejtowaniu Twojej pracy, tylko w sposób nie zawsze odpowiedni sygnalizują, że zależy im również na tym by Twoja praca miała jeszcze większy sukces. W końcu jeśli zaspokoisz upodobania starych misiów, to zaproszą oni również młodszych kolegów i poprawi się chociażby PR tych kursów. Wtedy każdy będzie znów zadowolony bo sytuacja będzie win-win.

Znów się rozpisałem. Eh.
Pozdrawiam :)

---

Nie wiem, może czegoś nie potrafię objąć swoim małym móżdżkiem. Po prostu część rzeczy mi się podoba, ale są też rzeczy, których nie potrafię przyjąć do wiadomości. Kłócą się one zupełnie z moim postrzeganiem nauki programowania i z tempem jego rozwoju

---

Spoko, myślę że mniej więcej rozumiem Twój punkt widzenia, dziękuję za naświetlenie szczegółów i poświęcenie na to czasu! Wydaje mi się że wiem już jak wygląda przynajmniej szkic Twojej wizji na to zagadnienie. Myślę że podobnie można taki szkic narysować na podstawie moich wypowiedzi. I to chyba tyle, ile uda się osiągnąć w dyskusji internetowej, więcej można by już tylko wyjaśnić na żywo. Pozdrawiam, dzięki za Twój głos w dyskusji!

Answer 2

Bo jego kursy to delikatne i przyjemne wprowadzenie dla osób które nie ogarniają kompletnie nic, a nie coś po czym się nauczysz

Nie wiesz jak zacząć - oglądasz kursy Zelenta, on ci dobrze wytłumaczy absolutną podstawę, później chcąc poszerzyć swoją wiedzę szukasz innych - większych kursów, w których tłumaczenie jest na niższym poziomie, albo aby zacząć kurs trzeba już ogarniać te podstawy

Answer 3

Ja przerabiałem tylko kurs języka c++, więc trudno mi się rozpisywać, aczkolwiek brakowało mi w tym kursie jeszcze jednego odcinka, który związałby wszystkie pozostałe.

Pan Zelent używa metody od ogółu do szczegółu. Problem w tym, że brakuje końcówki z tymi szczegółami. Mógłby to być np. film odpowiadający na najczęstsze pytania i porady na tym forum. Np.:

Dlaczego nie używać zmiennych globalnych, czy polecić inne narzędzia niż c++ Builder.

Jest tutaj dużo nowicjuszy, którzy mają doświadczenie tylko z tych poradników i dopiero na forum dowiadują się o tak podstawowych rzeczach.

Answer 4

Co do czasu trwania odcinka to nikt nie każe ci go oglądnąć za jednym razem, możesz go podzielić na części. Sam MZ też wspomina w niektórych odcinkach, żeby nie trzeba oglądać wszystkiego na raz.

Co do budowy strony na divach to mógł to tylko raz pokazać, a w kolejnych odcinkach budować zgodnie z HTML 5.

Nawet fajny artykuł.

Answer 5

Pan MZ mówił w którymś odcinku by do programowania/kodowania podchodzić z pokorą.

Właśnie dzięki tego typu artykułom taką pokorę czujemy. Dobrze że jest ktoś kto jest w stanie pokazać pozytywne cechy jak i błędy tych właśnie cech pozytywnych.

Właśnie tym jest otwartość umysłu by przyjmować taki kubeł zimnej wody, by potem szukać lepszych rozwiązań.

W programowaniu właśnie to jest potrzebne. Fajnie że zajrzałem do tego wpisu :-) dzięki.

Answer 6

Witam,

wiadomo, że nie istnieją kursy idealne. Wydaje mi się w tekście zbyt duży nacisk kładziesz na prowadzącego a mniejszy na kursanta. Trochę to naiwne myślenie że podczas jedno pełnego kursu nauczysz się w pełni jakiegoś jakiegoś języka. Można sobie wpisać na YT HTML5 in 2hours, przerobić taki kurs i uważać się za eksperta w dziedzinie html'a następnie krytykować ten kurs. Pan Zelent podkreślał, że robi zakres technologi webowych w tym html. Pokazuje rozwój html rozważając wcześniejsze możliwości table, divy, specjalne tagi. Czy to jest dobra droga? Kwestia gustu. Żeby konkretnie władać jakimś językiem programowania należy przerobić wiele kursów, tutoriali, książek oraz wykonać ćwiczenia. Po takim bagażu doświadczeń możesz porównać metody nauczania, style programowania, dostępne wersje itp. Na swoim przykładzie: przerobiłem kurs C++ p. Zelenta. Następnie wykonałem kilka projektów , poznałem bibiloteki, standardy a potem przerzuciłem się na framework Qt. Podsumowując to jak kodzimy zależy od nas samych a nie od jednego kursu. Jak ktoś jest dociekliwy, ambitny to da sobie radę(nawet zaczynając poznawać technologie złego kursu zawsze może to zmienić).

Pozdrawiam

Comments

Trochę to naiwne myślenie że podczas jedno pełnego kursu nauczysz się w pełni jakiegoś jakiegoś języka

Zacytuj mi fragment w którym pada takie stwierdzenie. Bo moim zdaniem nic takiego nie stwierdziłem

Pan Zelent podkreślał, że robi zakres technologi webowych w tym html. Pokazuje rozwój html rozważając wcześniejsze możliwości table, divy, specjalne tagi. Czy to jest dobra droga? Kwestia gustu.

Jeżeli przeczytasz moją rozmowę na ten temat z MZ (ten wątek), to się dowiesz że chodzi mi o coś zgoła innego...

Po takim bagażu doświadczeń możesz porównać metody nauczania, style programowania, dostępne wersje itp

Odpowiem innym przykładem: jeżeli ktoś robi błąd na zasadzie dzielenia przez zero i mówi, że jest to równe zero, to nie muszę posiadać tytułu profesora matematyki, aby móc mu powiedzieć że robi to źle. Podobnie jest tutaj

---

Odpowiem innym przykładem: jeżeli ktoś robi błąd na zasadzie dzielenia przez zero i mówi, że jest to równe zero, to nie muszę posiadać tytułu profesora matematyki, aby móc mu powiedzieć że robi to źle. Podobnie jest tutaj

Moim zdaniem to jest nietrafione porównanie, bo wiele decyzji dydaktycznych jest dyskusyjnych i co najmniej kilkuwymiarowych. A każda decyzja ma plusy i minusy. Porównanie  tego do dzielenia przez zero, to w mojej opinii zbyt duże uproszczenie, które nie oddaje rzeczywistości. Dopiero bycie dalej i posiadanie bagażu doświadczeń (i to najlepiej nie tylko swojego, ale także swoich podopiecznych, bo nie wszyscy mają te same preferencje osobowościowe co nauczyciel) pozwala mieć dobre rozeznanie - tak ja uważam. Pozdrawiam

---

Tak, zgadzam się z Panem. Zależało mi na przykładzie, który dobitnie pokaże, że nie trzeba mieć 10lat doświadczenia w it, aby móc komuś zwrócić uwagę, że coś da się zrobić lepiej ;)

Answer 7

A pozwolę sobie poruszyć jeden temat (jeśli można), mianowicie omawianie w filmach M. Zelenta nie do końca "nowych" rzeczy.
Proszę szanownych forumowiczów, głównymi odbiorcami M. Zelenta jest młodzież gimnazjalna i ponadgimnazjalna (tak mi się wydaje). Oczywistym jest fakt, że w przypadku technologii webowych wręcz należy mówić o nowych, a raczej aktualnie stosowanych technologiach, a o starszych, odchodzących do lamusa można tylko wspomnieć, że coś takiego było i tyle. Niestety w szkole uczymy właśnie tych starszych rzeczy. W podstawie programowej nie ma zdania na temat np. flexboxa, tylko jest np. float:left. Na egzaminie E.14 jest tak samo. Jako szkoła, jako nauczyciele musimy przede wszystkim przygotować uczniów do matury i egzaminów zawodowych. Proszę mi uwierzyć, że jeszcze 2 lata temu (albo 3, czas tak szybko leci, że się wydaje jakby to było wczoraj) był Windows XP. Takie są realia w polskich szkołach.
Oczywistym dla mnie jest fakt, że mądry nauczyciel, w miarę możliwości czasowych, stara się przygotować również uczniów do realiów związanych z pracą i omawia obecnie stosowane technologie.
Zresztą moje zdanie jest takie, że dobry fachowiec powinien znać zarówno starsze, jak i nowe technologie.
Podsumowując, omawiane technologie w filmach M. Zelenta są adekwatne do obecnego systemu szkolnego.
Pozdrawiam

Comments

" dobry fachowiec powinien znać zarówno starsze, jak i nowe technologie. "

Więc powiadasz, że jak jesteś inżynierem mechaniki, to musisz umieć używać trebusza?

---

To kiepski ten inżynier skoro nie zna zasady działania trebusza...
Idąc Twoim tokiem myślenia, np. dzisiejszy elektronik umiałby tylko naprawiać telewizory LCD, ale już telewizora kineskopowego nie dałby rady naprawić bo nie ma pojęcia co to jest!?

---

Może i zasadę zna, ale celowanie czymś takim to inna sprawa :P

Ogólnie przykład oddaje sedno sprawy, nawet jeśli nie jest idealny. Po prostu niektóre rzeczy wyszły z użycia, to po co je znać? Nic to nie wnosi, po prostu nic.

O ile np. rysowanie rysunków technicznych ręcznie jestem w stanie uzasadnić (w dobie CADów) to uczenie starych rzeczy w przypadku programowania totalnie mija się z celem.

---

Zgadzam się z Tobą w 100%. Niestety żyjemy jeszcze w takich czasach, że np. można spotkać strony WWW oparte na HTML4 lub XHTML. Nie każdego stać np. na postawienie nowej strony opartej na nowych standardach więc, aby coś na tej stronie zdziałać, poprawić, musisz znać HTML4 (wiem, że może jest to głupi przykład, ale mam nadzieję, że oddaje to, co mam na myśli). Zresztą pisałem o znajomości, a znajomość czegoś nie zobowiązuje nas, aby to stosować, czyli jak ktoś zna starsze technologie i nowsze (co tak być powinno), to nie musi stosować tych starszych kosztem nowszych :)

---

Okej, ale po prostu w tym momencie stare technologie to strata czasu. Rozumiem uczyć się tego z ciekawości "jak się kiedyś robiło".

Ale dobra, już za swoje wygłaszanie opinii o MZ i jego nauczaniu zostałem znienawidzony przez połowę użytkowników, a i tak powiedziałem już wszystko w tym temacie, więc EOTuję :)

---

Eee tam, ja wcale nie jestem za, ani przeciw temu tematowi, powiedziałem, co mi na sercu leżało i już, co znam od podszewki bo uczę od 9 lat informatyków i stąd moje przekonanie, że muszę znać zarówno stare jak i nowe technologie. Oczywiście, że używanie starych technologii mija się z celem, ale znajomość starych może pomóc w poznaniu i łatwiejszym opanowaniu nowych...
Każdy ma prawo do własnego zdania i jestem pewien, że nikt Cię nie nienawidzi
Pozdrawiam

---

" że nikt Cię nie nienawidzi "

Zostałem wielokrotnie zwyzywany od hejtera, idioty, czepialskiego, sfrustrowanego programisty, dzieciaka. Zarzucano mi niekompetencje i postawiono w bardzo złym świetle, choć jedyne co zrobiłem to wyraziłem ostrą, ale kulturalną krytykę. Choć na szczęście kilka osób trzymało moją stronę...

No nic, przynajmniej teraz wiem, na kogo nie warto tracić czasu :)

---

A to przepraszam, że wszedłem na taki temat...
Ja się już nauczyłem, że nie ma się co przejmować i brać do siebie tego wszystkiego co inni mówią. Miłego

Answer 8

Oczywiście, że kursy nie są doskonałe, arta nie czytałem, ale domyślam się o co w nim chodzi. W każdym razie mógłbym skopiować wypowiedź Benka i tyle.  Jako lekkie wprowadzenie do programowania idealne, a że programowanie jest nauką która nie kończy się na kursach, każdy powinien wiedzieć. Na prawdę jest mało, kursów które są idealne. Tzn przekazują wiedzę w przyjazny sposób a do tego są aktualne.  Dlatego jego kursy jako zachęcacz są idealne, a czy przerobisz jego kurs, czy inny płatny, najnowszy i w ogóle to bez znaczenia w obliczu początków nauki bo i tak do wszystkiego trzeba samemu dojść.

Comments

Hej, szkoda że nie przeczytałeś. Bo nie uważam że wypowiadanie "swojej" opinii zgodnej z nurtem ogólnej opinii jest fajna ;)

Mimo wszystko zachęcam do lektury

---

To raczej jest moja opinia którą podtrzymuję od czasu tej wielkiej burzy kiedy MZ przekazał forum.  Opinia niezmienna, a benek ją tylko potwierdził.

Przeczytam wieczór moze.

---

Ok :)

Answer 9

O ile niektóre materiały od Zelenta są w miarę ok, o tyle kurs C++, który w całości przerobiłem jest bardzo kiepski. Jednym jego plusem jest to, że to co ukazane jest w nim dobrze ukazane jest w bardzo przystępny sposób dla nowicjusza. Ale pominięcie wielu ważnych kwestii, których nawet na początku nie powinno się pominąć, złe praktyki programistyczne, używanie przestarzałego C++Buildera 6 zamiast np. Qt, itp. to tragedia. Napisałem o samym tym kursie podobną recenzję: https://forum.pasja-informatyki.pl/270033/kurs-programowania-w-c-miroslawa-zelenta-moja-opinia

Comments

Qt nie jest IDE, czemu więc porównujesz je z C++ Builderem? Wiem, pewnie chodzi o Qt Creator, ale wytykasz innym błąd, więc nie popełniaj sam innych…

Aha, nie jestem z #GangZelenta…

---

Wiem, pewnie chodzi o Qt Creator, ale wytykasz innym błąd, więc nie popełniaj sam innych…

(To raczej dość powszechny skrót myślowy)

---

Mówiąc "Qt" mam na myśli używanie zarówno samej biblioteki(bo bez QtCreatora też da się jej używać) jak i też QtCreatora.

Answer 10

No to i ja przeczytalem, wiec

Jako osoba, ktora ogladala filmy, zarowno z C++ i podstaw webowki (3 filmy), to widze takze bledy, ktore mozna zauwazyc w ksiazce szkola programowania, czy symfoni. Osobiscie sam zaprzestalem ogladac filmow w momencie, ktorym do gry wszedl Builder, ktory jest stary (lekko mowiac). Ale w kursach Pana Miroslawa, oprocz bledownych standardow, jest tak jak kazdy wapiminal, cos co zachecilo wiele osob, ktore sie pojawiaja na tym forum do kodzenia. Samo podekscie jest rewelacyjny, a jak sie nie myle, to w jedym z odcinkow Pan Miroslaw wapominal, ze kurs to niejedyne zrodlo wiedzy i mysle, ze to jest to wazna rzecz, ktora powinnien zrozumiec kazdy poczatkujacy. Jak wiadomo, wiekszosc do nauki wybiera tylko jeden kurs, co jest raczej bledne i chesto prowadzi do bledow, ktore walkujemy wlasnie tu na forum, ale dokladnie kest to samo z zadawanymi pytaniami, ktore najczesciej wygladaja tak:

Mam problem, program nie dziala, wklejam kod jak zwykly tekst i pytam co nie dziala.

Mysle, ze to takze wina mentalonsci ludzkiej, ktora chetnie ciagnie do Pana Miroslawa, bo ma fantastyczne zdolnosci dydaktyczne, i ludzie mysla, fajnie mowi to po co mi cos nowego?

Podsumowujac, zgadzam sie z Toba, ze kursy nie sa idealne, ale trzeba jasno powiedziec kazdemu ,kto zaczyna z programowaniem, ze jedno zrodlo wiedzy, jest jak jedna studnia w miescie, kiedys woda sie skonczy.

Pozdrawiam DC

Answer 11

Oj nie wiem czy wiesz że Pan MZ robi kursy dla techników gdzie  nie potrafią przygotować do e13 i e14

jak ktoś chce iść dalej to sam znajdzie swoją drogę....I jeszcze jedno kolego nie ma rzeczy idealnych na tym swiecie

Comments

"Kolego" radze nauczyć czytać się ze zrozumieniem, bo we wnętrzu arta na samym początku napisałem, że interesują mnie wyłącznie Kursy programowania.

Btw ten sam wniosek co podałeś wynika z treści wpisu, bazując na Twojej opinii wynosze że nawet nie raczyles zajrzeć na bloga...

---

Post ten nie miał na celu wytknięcia, jaki to ten kurs jest do niczego, tylko pokazanie, że ma swoje wady i nie należy ufać w 100% przekazywanej w nim wiedzy. Niestety wciąż wiele osób tego nie rozumie.

Nie wiem więc skąd to oburzenie.

---

ale ja wiem o co ci chodzi Panie drogi :) myślisz że w technikum potrafią wytłumaczyć

np c++? albo PHP .Jak masz wytykać komuś nie doskonałość to daruj sobie bo nikt nie jest doskonały prawdą jest to że to są tylko podstawy :)

---

Mało mnie interesuje to czy w twoim technikum nikt nie potrafi tego lepiej wyjaśnić ;)

Faktem jest to że są rzeczy, które można zrobić lepiej, a nawet powinno się zrobić lepiej. Jeżeli tego jeszcze nie rozumiesz to ochlon, pogadamy za kilka lat gdy zrozumiesz.

A dlaczego wytykam błędy? Bo to na tym polega: nauczyciel też to robi, abyś mógł je zauważyć i zacząć coś robić dobrze. Chcę aby sieć i ogólnie kod był jak na najwyższym poziomie, zauważ ze moje uwagi nie pozostają bez uzasadnienia, mają w tym jasno określony cel.

Na pewno nie są tak pretensjonalne jak twój komentarz :)

Zauważ, że póki co wszyscy się ze mną zgadzają, zapytaj kogokolwiek doświadczonego na irc co myśli na temat tych kursów a odpowie ci mniej więcej to samo co ja

Answer 12

Rozumiem że pisząc to chodzi Ci o feedback ponieważ nie zadałeś żadnego pytania

W artykule stwierdziłeś oczywistą prawdę. Nie podoba mi się on, ponieważ nic nie wnosi do mojego życia. Niczego mnie nie nauczył.  Uważam że na swojej stronie robisz świetną robotę jest tam wiele merytorycznych artykułów. Sugeruję Ci żebyś trzymał się tej konwencji tzn uczył jak coś zrobić zamiast oceniać prace drugiej osoby.

Comments

Ta prawda nie jest oczywista dla wszystkich (patrz komentarz Davida).

Jeżeli dla Ciebie jest oczywista to świetnie ;)