Na kanale eduweb.pl właśnie trwa live z otwarcia ich frontendowego bootcampu. Z racji tego, że zaciekawiła mnie jego reklama, postanowiłem przyjrzeć mu się nieco bliżej.
-
Moją ciekawość wzbudziła już sama próba wytłumaczenia, czym jest front-end, gdy usłyszałem, że
to proces
– wszystko na podstawie artykułu z Wikipedii. To chyba najbardziej dziwne wytłumaczenie tego pojęcia. Otóż nie, front-end to nie jest proces. Procesem jest generowanie strony i przesyłanie jej z serwera do przeglądarki. I proces ten angażuje zarówno back-end, jak i front-end.Najprostszym wytłumaczeniem tych pojęć jest stwierdzenie, że back-end to serwer obsługujący stronę a front-end to to, co widzimy w przeglądarce. Wytłumaczenie o wiele prostsze i dające o wiele większe możliwości rozwinięcia całego tematu.
-
W całej pierwszej części uparcie powtarzany jest termin SPA, który wydaje się nadmiernie rozciągnięty. Pada bowiem stwierdzenie, że każda strona, która się nie odświeża albo która używa Ajaksa, jest SPA. I jako przykład takiej aplikacji jest podany GMail.
Tutaj mam pewien dylemat, ponieważ typowe SPA raczej nie aktualizują adresu pod wpływem interakcji z użytkownikiem (mimo że Wikipedia twierdzi inaczej). Udają bowiem aplikacje desktopowe, które po prostu adresu nie mają. W przypadku GMaila każdy stan posiada własny URL, przez co bardziej przypomina tradycyjną aplikację internetową. Nie mogę się także zgodzić, że każda strona, która się nie odświeża, to SPA. A co z klasycznym wykorzystaniem pjaxa, żeby po prostu uczynić normalną stronę bardziej interaktywną?
SPA to jednak bardzo specyficzny rodzaj aplikacji internetowych, który niekoniecznie się sprawdza w praktyce. Bardziej wierzę w izomorficzne aplikacje internetowe, aka „uniwersalny JS” – choćby przy pomocy takich „super trendy” frameworków jak next.js, w których PE jest wciąż żywe. W sumie to bardzo smutne, że obecnie generowanie strony na serwerze to jedno z największych odkryć front-endu. Znów wymyślamy koło na nowo.
-
Następnie następuje próba udowodnienia, że podstawowa wersja GMaila w prostym HTML-u bez JS-a jest wolniejsza na klasycznym połączeniu 3G niż wypasiona wersja. Porównanie to ma jedną, bardzo zasadniczą wadę: nie bierze pod uwagę czasu 1. wczytania strony. A JS-owa wersja GMaila jest na tyle duża i zawiera tak dużo kodu JS, że… jej wczytanie zabierze wieki. Stąd wersja prosta jest zdecydowanie szybsza na wolniejszych łączach. Zresztą próba udowodnienia tego była dość mizerna, zważając na fakt, że cały interfejs GMaila w wersji podstawowej wczytywał się w… 250 ms. To raptem o 50 ms wolniej niż wczytanie kolejnej porcji mailów w wersji Ajaksowej.
Kolejną próbą udowodnienia większej wydajności wersji ajaksowej było porównanie procesu gwiazdkowania e-mailów. Otwarto dwa okna podstawowej wersji GMaila, po czym w jednym zagwiazdkowano mail i pokazano, że w drugim nic się nie zmieniło, co ma wskazywać na pokazywanie niewłaściwego stanu aplikacji. Pomijając już fakt, że nikt nie otwiera dwóch GMaili naraz (albo robi to bardzo, bardzo rzadko), to nie można też twierdzić, że aplikacja pokazuje zły stan! Aplikacja pokazuje ostatni zsynchronizowany z serwerem stan. Ten stan jest aktualny w chwili ostatniej komunikacji z back-endem. Zarzucanie tradycyjnemu modelowi klient-serwer pokazywania niewłaściwego stanu aplikacji jest grubym nieporozumieniem.
Zresztą porównanie klasycznego gwiazdkowania z gwiazdkowaniem w wersji ajaksowej również było wykonane niepoprawnie, ponieważ nie otwarto dwóch interfejsów GMaila, ale… otwarto podgląd e-maila w okienku popup. To oznacza, że zaznaczenie gwiazdki w tak otwartym okienku nie oznacza komunikacji z serwerem. Główne okno mogło zostać poinformowane o zmianie stanu poprzez bezpośrednią komunikację z okienkiem popup. Jeśli chcielibyśmy zobaczyć jak przebiega prawdziwa synchronizacja ajaksowego interfejsu GMaila z serwerem, warto by otworzyć dwa okna GMaila (i to nawet w różnych przeglądarkach, bo karty w tej samej przeglądarce mogą się komunikować między sobą) lub pobawić się gwiazdkowaniem na telefonie. Ręczę, że tak szybkiej reakcji nie uświadczymy.
- Następnie pada stwierdzenie o
serwerach frontendowych
iserwerach backendowych
. Problem polega na tym, że nie istnieją serwery frontendowe. Możemy co najwyżej mówić o middleendzie. Natomiast serwer backendowy to pleonazm. - I nie, npm nie oznacza
node package manager
! npm to po prostu npm, czego dowodzi repozytorium „oficjalnych” rozwinięć skrótu. Zresztą jak menager pakietów dla całego ekosystemu JS mógłby mieć w nazwie node? - Następnie pada stwierdzenie, że serwer HTTP należy uruchomić na porcie 80, bo
na tym porcie działa przeglądarka
. Totalna bzdura. Przeglądarka nie działa na żadnym porcie, bo nie ma po co. Zresztą bardzo łatwo to udowodnić: gdyby przeglądarka działała na porcie 80, to nie dałoby się na tym porcie uruchomić serwera (byłby już przecież zajęty). Pomijam fakt, że obecnie Sieć migruje na HTTPS, więc coraz częściej zamiast portu 80 jest wykorzystywany port 443 (lub dowolny inny, jaki skonfiguruje sobie administrator serwera). - Pada także stwierdzenie, że format JSON jest poprawnym JS-em. Nie jest.
- Nie rozumiem, czemu Ajax = jQuery. Mamy 2016 rok, istnieje Fetch API, które jest o wiele łatwiejsze do wytłumaczenia niż jQuery. Pomijam fakt, że nie da się tłumaczyć Ajaksa bez wytłumaczenia asynchroniczności – czego doskonałym dowodem jest twierdzenie, że przypisanie rezultatu
$.getJSONdo zmiennej nie działa, podczas gdy konsola wyrzuciła ładny obiekt XHR z gotową odpowiedzią. - Kolejnym problemem związanym z Ajaksem, który pojawił się na tym filmie, jest potraktowanie po łebkach HTTP – zarówno samego postawienia serwera, jak i nagłówków. Tym samym cały przykład nie działał, bo jQuery pobrało odpowiedź z cache przeglądarki a nie serwera. Rozwiązanie tego przez doklejenie aktualnego czasu do zapytania jest po prostu słabe, zważając na fakt, że jQuery ma odpowiednie opcje od tego, a na samym serwerze można wyłączyć cache’owanie poszczególnych zasobów.
- Tyle z pierwszej godziny – potem odpadłem. Niemniej z części drugiej usłyszałem, że wersja alpha to
prawie gotowa do użycia
(w kontekście Bootstrapa 4). Otóż nie. Wersja alpha to wczesna wersja danego oprogramowania, której nie powinno się używać w środowisku produkcyjnym. Po wersji alpha następuje jeszcze wersja beta (bardziej stabilna) i często jeszcze RC. I dopiero RC są na tyle stabilne, żeby można było zacząć myśleć o użyciu na produkcji. Wersja alpha często jest masakrycznie zabugowana.
PS To niby live z dzisiaj (6 listopada 2016 roku), a w Google wyraźnie widać logo z Halloween…
PS2 A na swoim profilu na Facebooku ładnie cenzurują. Serio.
Comandeer niezwykle cieszymy się, że zaciekawił Cię nasz Bootcamp! To świetnie, że postanowiłeś go sprawdzić i dzięki za poświęcony czas na komentarze. Super, że podlinkowałeś nasz kanał a tym samym propagujesz nasze treści! 😉
Pozdrawiamy,
Zespół eduweb.pl
Tylko do jednej rzeczy chcę się przyczepić: nie rozumiem zdania „Mamy 2016 rok, istnieje Fetch API”. W dokumentacji Mozilli do której zalinkowałeś jest zaznaczone grubymi literami że jest to technologia eksperymentalna i jeszcze nie ostatecznie ustandaryzowana. W dodatku z tego co widzę na caniuse.com, wsparcie jej jest bardzo dziurawe.
Dlaczego więc nie traktujesz tego tematu z takim samym dystansem, jak wspomniana niżej alpha Bootstrapa 4?
Czy ja wiem czy takie dziurawe? Safari jest jedyną przeglądarką, która nie wspiera. Niemniej istnieje bardzo fajny polyfill (dodatkowy plus dla kursu: uczymy posługiwania się polyfillami!). Z tą standaryzacją też nie jest tak do końca, bo – jak widać na Can I Use – jest to tzw. „Living Standard”, więc po prawdzie to same implementacje wpływają na kształt standardu mocniej niż standard na kształt implementacji. Z tego też powodu jest to technologia o wiele bardziej stabilna niż alpha jakiegoś frameworka CSS-owego.
Szanowny Panie Comandeer – pozwolę sobie tak się do Pana zwracać ponieważ nie podpisuje się Pan imieniem i nazwiskiem. Raz jeszcze dziękuję za konstruktywne podejście i uwagi, które tak jak obiecałem, zostały przekazana do autora.
Na początku mój komentarz:
Staramy się do naszych kursów wybierać najlepszych ekspertów – praktyków, nie mniej jednak zawsze słuchamy także opinii osób, które biorą udział w naszych wydarzeniach. W kontekście Pana posta, pozwalam sobie zatem przesłać wyniki ankiety w której wzięło udział ponad 50 osób, które oglądały Sesje Otwarcia. 97% osób uznało sesję, którą Pan opisał powyżej, jako „Dobrą” lub „Bardzo Dobrą”, czyli wystawiło jej najlepsze oceny: https://goo.gl/w33we4
Tytuł Pana posta błędnie sugeruje, że ocenia Pan cały Bootcamp. Ocenił Pan mniej niż 1% materiałów Bootcampu. Proszę mieć świadomość kontekstu – Kick Off, to odniesienie do 6 tygodni(!) Bootcampu w 6 godzin. Celowo nie przedstawiamy w nim zagadnień w sposób bardzo dogłębny, tak jak to Pan analizuje. Na Bootcampie każdy z Elementów Kick-Off jest omawiany szczegółowo i większość sugestii, które Pan podniósł jest w materiałach. Kick-Off jest przygotowany z myślą o osobach początkujących, stąd wiele uproszczeń, które mają po prostu na celu bardziej przystępne omówienie zagadnienia.
Dokładność jest bardzo ważna, ale przecież nie zaczynamy nauki matematyki od całek, a fizyki od termodynamiki. Osoby początkujące wchodząc w temat stopniowo mają okazje zobaczyć wady, zalety czy po prostu niedokładność prostych koncepcji i definicji. To ma na celu właśnie 6 tygodniowy Bootcamp – nie wrzucić na głęboką wodę „najnowszego i najlepszego”, ale zacząć od znanych i prostych rozwiązań stopniowo wprowadzać w te nowsze, lepsze, dokładniejsze i potężniejsze.
Kolejną sprawą jest natura wykładu, który nie był w żaden sposób montowany/edytowany – nie jest to pisanie książki, gdzie każde zdanie może Pan przeanalizować, rzeczą zupełnie naturalną są drobne potknięcia czy przejęzyczenia, wiele z nich Pan wyłapał i jest to oczywiście Pana prawo a nasz błąd z którym jednak musimy się pogodzić, inaczej nie moglibyśmy robić tego, co robimy.
Napisał Pan, że Pana celem było przekazanie sugestii do autora. Moim zdaniem, mógł Pan to osiągnąć inaczej niż publikując je w taki sposób. Jesteśmy zawsze otwarci na sugestie i dokładamy wszelkich starań, aby nasze materiały były jak najlepsze. Nie jesteśmy nieomylni i niezwykle cenimy konstruktywną krytykę.
To, co spowodowało usunięcie postów z Facebook’a, to właśnie forma w jakiej postanowiliście tą krytykę wykonać – umieszczając ją w komentarzu trwającej na żywo transmisji, gdzie nie mieliśmy możliwości się do niej odnieść czy obronić, opatrzoną hasłami „gniot” i „dezinformacja”. Nie jest to rodzaj retoryki, której używa się w konstruktywnej dyskusji i z tego powodu komentarz został usunięty. Nie pomogło także to, że i nasz komentarz zniknął od razu z Pana strony, co wyjaśnił Pan trafieniem do spamu, natomiast my mieliśmy pełne prawo aby podejrzewać, że został wykasowany.
Wyjaśnię też jeden zarzut który pojawiał się w komentarzach – Mateusz przez 10 min debugował błąd, co zostało przez Państwa odebrane jako nieprofesjonalne. W naszej ocenie w programowaniu właśnie o to chodzi, aby pokazać też proces rozwiązywania błędów, które są codziennością w pracy programisty. To, że nie znalazł rozwiązania było podstawą do pokazania, jak przywrócić działającą wersję strony z pomocą Git, a więc w pewnym sensie wyjść z opresji z pomocą narzędzia pokazanego wcześniej. Ten fragment zyskał wiele pozytywnych komentarzy w ankiecie, m.in.: „Bardzo fajnie, że w trakcie wyszedł problem z konfiguracją, to jest chleb powszedni każdego programisty ;)”
Panie Comandeer – dziękuję za Pana uwagi i doceniam je, ma Pan do nich pełne prawo. Nie spodziewałem się też niczego innego niż krytyki, bo tak wygląda każdy Pana wpis. W mojej ocenie swoją wiedzę i energię mógłby Pan jednak spożytkować w lepszy sposób (w zasadzie nie tylko swoją ale także naszą, bo w czasie kiedy odnosimy się do Pana uwag moglibyśmy stworzyć jakiś ciekawy materiał) – dlatego zapraszam do spróbowania swoich sił w nagrywaniu materiałów dla nas.
Z poważaniem,
Grzegorz Róg
Eduweb.pl
Poniżej jeszcze komentarze od Autora:
1. To zapewne przejęzycznie – chodziło dokładnie o proces generowania treści w Back-Endzie i przesyłanie do Front-Endu. (Jak w art. na Wikipedii.) Dokładnie jak w artykule – serwer (back-end) odbiera żądania i odsyła dane, a front-end „za to co widzimy przeglądarce”.
Pierwsza sesja wprowadzenia do Bootcampu była przypominająco / uzupełniająca dla osób, które nie miały styczności z Front-Endem, SPA, AJAXem, itp. dlatego nie była istotna tyle słownikowa dokładność co jak najprostsze i najbardziej przystępne pokazanie zasad działania „procesu” od serwera do przeglądarki, oraz korzyści płynących z przesunięcia części mechanizmów aplikacji z serwera do przeglądarki. W samym Bootcampie pojęcia takie jak Back-End, Front-End, AJAX, XHR, mechanizm HTTP, kody HTTP, nagłówki, czym jest JSON a czym nie jest, itd. – wytłumaczone są już dokładnie, na przykładach z dbałością o ich poprawność ale głównie o przystępność i łatwość zrozumienia na potrzeby codziennej pracy z tymi technologiami.
Wytłumaczenie, że „Przeglądarka działa właśnie na porcie 80”, służyło wytłumaczeniu dlaczego serwer uruchamiamy na tym porcie (przełącznik „-p 80”) – ponieważ przeglądarka łączy się z serwerem (działa) właśnie na tym porcie. Nie jest też wytłumaczone działanie HTTP, DNS, SSL, i wielu innych pojęć na które miejsce i czas jest już we właśniwych lekcjach Bootcampu.
2. Single Page Application – To aplikacja internetowa, która działa właśnie (jak nazwa wskazuje) „na jednej stronie” w przeglądarce i to jest głównym założeniem tej koncepcji. To czy zmieniamy adres URL nie jest częścią definicji, aczkolwiek jest to bardzo popularna praktyka (Google, Facebook, i wiele innych), gdyż pozwala na łatwe linkowanie do aktualnego stanu jak to ma miejsce na zwykłych stronach ( łatwe dodanie do zakładek czy udostępnienie odnośnika).
Oczywiście podejścia SPA, aplikacji uniwersalnych i wiele innych – to wszystko jest wytłumaczone w kolejnych tygodniach – także jak obyć się bez jQuery, jak generować aplikacje w node.js, jak komunikować się z nią przy użyciu WebSockets i wiele więcej.
Cały postęp polega na odkrywaniu koła na nowo. Na przykład koncepcje funkcyjne z React i Redux mają ponad 30 lat, multimedialne aplikacje mamy też od lat – Bootcamp ma na celu pokazanie, że te technologie, te dostępne są tu i teraz w każdej (nowej) przeglądarce i każdy może się ich nauczyć i zacząć z nich korzystać. Ważne jest by pokazać najpierw w przystępny sposób ich praktyczną stronę, a dopiero potem wchodzić stopniowo w definicje i szczegóły.
3. Założeniem SPA jest to by po pierwszym załadowaniu wymieniały minimum danych z serwerem – więc z założenia są szybsze w użytkowaniu (gdy już się załadują) od tradycyjnych aplikacji wymagających każdorazowego przeładowania strony. Oczywiście koncepcje takie jak app shell czy aplikacje uniwersalne są kolejnym (bardziej zaawansowanym, a jednocześnie wcale nie odkrywczym) krokiem by aplikacje SPA działały jeszcze szybciej.
GMail funkcjonuje w zupełnie inny sposób niż typowe SPA i komunikacja między oknami odbywa się bez udziału sieci. Niemniej Gmail jest aplikacją dobrze znaną, a dzięki widokowi HTML pozwala na prostym przykładie świetnie pokazać różnice koncepcyjne w działaniu aplikacji SPA, a tradycyjnej aplikacji internetowej.
Nie ma serwerów front-endowych, ale są proste serwery lokalne nie wymagające konfigurowania, a przez to ułatwiające znacznie prace front-end developera.
Bootcamp jest dla osób które mają wcześniejsze doświadczenie z tworzeniem stron internetowych. Dla wielu z tych osób niestety AJAX == jQuery, dlatego chcieliśmy wyjść od czegoś co jest znane. jQuery nie trzeba tym osobom tłumaczyć. Fetch API – już tak. W kolejnych lekcjach i zadaniach bootcampu uczestnik oczywiście dowiaduje się jak pracować sprawnie z JavaScript także bez konieczności używania jQuery. Odnośnie opcji – cache – wymaga ona pełnego rozwinięcia metody $.ajax() zamiast prostego $.getJSON() – ponownie, na potrzeby szybkiego wprowadzenia byłoby to zaciemnianie obrazu szczegółami (cache, jquery api, http, itp.) zbędnymi na tym etapie omawiania tematu, a omówionymi szczegółowo, na przykładach podczas samego bootcampu.
Jeśli chodzi o Bootstrap4 – wprowadzenie, lub (demo) nie jest w żadnym stopniu zastosowaniem produkcyjnym, a cała stworzona (w nieco ponad godzinę!) aplikacja jest także daleka nawet od wersji „alfa”. Jeśli ktoś oczekuje by po obejrzeniu kilku godzin nagrania stworzy od zera aplikacje gotową do użycia produkcyjnie – to może być mocno zaskoczony.
Pan Comandeer ewidentnie dysponuje szeroką wiedzą z zakresu tworzenia aplikacji internetowych. Czy wykorzystanie tej wiedzy do wychwytywania niespójności, przejęzyczeń i błędów językowych to najlepsze jej zastosowanie? Nie nam to oceniać. Niemniej bardzo dziękujemy za wszelkie konstruktywne uwagi!
Autor – Mateusz Kulesza
Eduweb.pl
Otóż nie, faktycznie, nie jest to najlepsze jej zastosowanie. Dlatego oprócz wytykania błędów zajmuję się także działalnością „edukacyjną”, udzielając się jako administrator na ForumWeb.pl, moderator na Forum.Pasja-Informatyki.pl, normalny user na Forum.PHP.pl, uczestnik na kilku grupach FB poświęconych webdevowi, autor książki o JS i kilku ciekawych artykułów na kilku portalach oraz mentor dla co najmniej jednego webdevelopera. I dopiero na końcu wypada także wspomnieć, że jestem redaktorem WebKrytyka, który w gruncie rzeczy wpisuje się bardzo ładnie w resztę mojej sieciowej działalności, jako niejako duchowy następca legendarnych Osiołków.
Ale jaja 🙂 Comandeer skrytykował eduweb i od razu kontra 🙂 grubo 🙂 swoją drogą zawsze czekałem na pierwszą osobą, która to zrobi bo szczerze powiem, że znam ich stronę, nawet przerabiam ich kurs ale to później. Znam ich i jeszcze nie spotkałem się z jakąś krytyką od kogoś kto się naprawdę zna na rzeczy jak właśnie Ty Comandeer i jednak nie są tak bezbłędni jak myślałem 🙂
A kurs, który od nich zakupiłem to kurs „Javascript od podstaw” i powiem szczerze, że marzy mi się byś przerobił ten kurs i obiektywnie go ocenił bo osobiście chyba jesteś jedną z najbardziej ogarniętych osób w Polsce jeśli chodzi o JS i bardzo cenię Twoje zdanie. Naprawdę byłoby to ciekawym wydarzeniem(dla mnie mega ciekawym) gdybyś wyraził swoją opinię na temat tego kursu i wytknął im wszystkie błędy :D.
Comandeer ogólnie nie mam tyle pieniędzy co mają Polscy programiści ale jak zacznę już zarabiać jako front-end developer czy javascript junior i moje życie wyjdzie na prostą to obiecuję, że kupię twoją książkę. Chyba jeszcze żadnej książki nigdy nie kupiłem ale zrobię to za całą twoją pomoc dla mnie i wszystkich innych użytkowników na forumweb, za tą stronę, za to że jesteś ogar i że nawet eduweb musi się liczyć z Twoją opinią 😀 za to, że pomagasz nie tylko na forumweb.pl bo widziałem Twoje komentarze na wielu stronach. Ogólnie wielki szacun :D. Chciałbym kiedyś być taki dobry w JavaScript jak Ty :D.
A tak w ogóle to gratuluje książki. Nie raz widziałem jak się ludzie pytali o jakąś konkretną książkę do JS i pisałeś, że jak jakaś dobra to po angielsku a jeśli chodzi o język Polski to nie ma i że chyba będziesz musiał ją wreszcie napisać, a tu proszę, książka wydana. Gratuluje.
Powodzenia i pozdrawiam aha Eduweb, dla mnie Comandeer też jest mentorem czyli już jest na dwóch.
I nie jest to komentarz sponsorowany 😀 po prostu doceniam pomoc innych dla innych.
Dzięki za miłe słowa! Podeślij mi adres na maila (comandeer@comandeer.pl), to dostaniesz książkę 😉
Biorę udział w bootcampie, przerobiłem na Eduwebie wszystkie kursy z JS, a jednocześnie znam i cenię działalność Comandeera 🙂
Z jednej strony uważam, że ekipa Eduweb robi świetną robotę, chwała im! – ale z drugiej strony ukłony dla Comandeera, że wychwytuje ich lapsusy. Choć uważam, że mocno przesadza w artykule. Na pewno są kursy, gdzie konstruktywna krytyka Comandeera byłaby na wagę złota. Zapłaciłbym potrójnie, by zobaczyć jakiś warsztat Twojego autorstwa 😀
@Dawid: kurs Piotra Palarza „Javascript od podstaw” jak również „Javascript w praktyce” to dla mnie świętość. Nie ma tam błędów i basta 😛 Pewne kwestie można by rozwinąć, inne inaczej ująć – ale całokształt jest IMHO genialny.
Jak już potrójnie płacą, to chyba trzeba się zastanowić… 😉
Podpisuję się pod tym obiema rękami!
Lubię Twój styl pisania, czuję się tu jak w domu..
Czekam na nową, solidną dawkę wytknięcia błędów. Uczysz i bawisz przy okazji, jak tylko pierwszy raz tu trafiłam, to wiedziałam, że zostanę na dłużej.
Dziękuję, podziwiam i pozdrawiam 🙂
Witam
Lubię kursy eduweb.pl
Cieszę się, że są takie dyskusje, nawet burzliwe
Pozdrawiam
Ciekawa dyskusja. Fajnie, że wypowiadają się obie strony. Dzięki temu zostaje zachowany obiektywizm i można samodzielnie wyciągnąć wnioski. Zamierzam się zapisać na ten frontendowy bootcamp w maju i zobaczyć jak to będzie wyglądało merytorycznie. Ogólnie z materiałami eduweb już miałem styczność, poziom moim zdaniem trzymają, także i tutaj spodziewam się profeski.
Pozdrawiam!
Kupiłem kurs CSS3 od eduweb i byłem (nadal jestem) nim zachwycony. Ciekawy projekt, użyteczne przykłady. Będąc zadowolonym zainwestowałem w responsywne strony czy tam elastyczne strony www – niestety co do tego zakupu mogę jedynie potwierdzić słowa Pana Comandeer’a – suche przykłady. Kurs traktuje o projektowaniu a widząc pierwszy raz projekt końcowy odechciało mi się jego dalszej realizacji. Niemniej jednak zapłaciłem, przerobiłem – raczej z bólem. Miałem więc – pozytywne i negatywne wrażenia za sobą; Postanowiłem dać im jeszcze jedną szansę. Kupiłem kurs preprocesorów. Niestety powtórka z rozrywki – sucha teoria jakieś dziwne, bezużyteczne przykłady. Ukończony kurs – owszem z masą wiedzy ale co z tego jeśli nie wiadomo co z nią do końca zrobić… Zapomniałbym napisać o tym, że w każdym z kursów w sposób denerwujący prelegenci namawiają do zakupów innych kursów, dla mnie teksty w stylu ,,omówię to tylko pobieżnie jeśli chcecie znajdziecie o tym informacje w kursie xxx” są co najmniej odstraszające. Macie tutaj wrażenia osoby początkującej – czyli takiej (jak mniemam), do której kierowane są tego rodzaju kursy. Po doświadczeniach z innymi zagranicznymi portalami zarówno ,,ja jak i moi znajomi potwierdzą” (zabrzmiało jak w clickbaitowym nagłówku xD), że jeśli tylko znacie język angielski to kupujcie ,,za granicą” jeśli nie to czym prędzej się nauczcie ;).
Pozdrawiam serdecznie Panie Comandeer!