•  

    pokaż komentarz

    W JavaScripcie jest tylko jeden wzorzec...

    pokaż spoiler http://pl.wikipedia.org/wiki/Spaghetti_code ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @BeSmarter: Tak było lata temu. Teraz JS to przyzwoity język, z dużymi możliwościami. Dobrym przykładem jest framework EmberJS, który pozwala na pełny MVC w JavaScriptcie - jedynie trzeba dopisać model pobierany np po AJAXie.

      Korzysta z tego między innymi Discourse i trzeba przyznać, że kod Discourse + EmberJS jest na prawdę elegancki i dużo łatwiejszy do utrzymania niż klasyczne generowanie HTMLa po stronie serwera. A przy obecnym postępie w standaryzacji już nie trzeba się aż tyle bać o to, że na jakiejś przeglądarce coś nie ruszy.

    •  

      pokaż komentarz

      @wojciechka1: Tearaz JS to ten sam język, co lata temu. Dorobił się ostatnio całkiem niezłych protez, ale nawet najlepsza proteza niie jest lekarstwem. MVC? Po kiego grzyba, skoro JS na potencjał na V i może 1/2 C?

    •  

      pokaż komentarz

      @evapor: Fakt, część rzeczy jest protezami (jak np XMLHTTPRequest, który historycznie po prostu jest nazwą klasy COM dostępnej w IE - reszta wzięła nazwę, bo pasowało). Ale tak jest chyba w każdym języku (jak chociażby w PHP, ale nawet np własne rozwiązania Springa, które dopiero po latach próbuje się zintegrować ze standardami JEE). JS jest zresztą trochę jak PHP - można w nim zrobić wiele dobrych rozwiązań, i bardzo wiele złych rozwiązań.

      Natomiast w JS przez lata ustandaryzowało się chociażby API do przeglądarek, zachowanie różnych dziwnych przypadków, wielokrotne przyspieszenie samego języka oraz funkcji przeglądarki. jQuery nie powstałby w czasach IE 4.0/NN.

      Co do MVC - to nie jest kwestia języka, ale jak podejść do odpowiedniego rozbicia M V i C. Przy grubych klientach podobnie większość M i część C jest na serwerze a część M i C i całe/większość V na kliencie - ale ważne, żeby to zrobić z głową. Zresztą tą część modelu (np walidacje), którą trzeba uruchamiać w obu miejscach można spokojnie napisać w JS i po prostu odpalać i tu i tu.

      przy każdym nietrywialnym rozwiązaniu część rzeczy robi się na serwerze, a część na kliencie. Jedynie generowanie całego HTMLa na serwerze nie ma tego problemu, ale ma masę innych problemów - jak np przeładowywanie 10 artykułów, żeby zapamiętać wynik sondy.

    •  

      pokaż komentarz

      @BeSmarter:
      @evapor: jak się nie potrafi pisać, to nawet w Ruby napisze się paskudny kod.

    •  

      pokaż komentarz

      @wojciechka1: a najlepszą możliwością jego możliwością jest... CoffeeScript.
      Używałem Backbone, próbowałem Embera, a najchętniej korzystam z Angular JS. To są frameworki, one nie naprawiają w żaden sposób języka.

      Kiedyś naczytałem się sporo o JS, jaki to on jest kijowy i w ogóle do dupy. Pomyślałem, że to nie prawda, że po prostu trzeba spędzić nad nim więcej czasu, "poczuć" go i wtedy cały ten "flow" będzie lepszy. Zacząłem uczyć się wzorców, czytać, szukać rad. Próbowałem naśladować konstrukcje i zachowania języków, które znałem, np. Ruby. Mimo wszystko programowanie w JavaScripcie ciągle bolało. Na szczęście odkryłem CoffeeScript i uważam, że wreszcie mamy solidną i sensowną nakładkę na JS.
      Główny problem z CS jest w tej chwili taki, że ludzie boją się, że część bibliotek/frameworków/kodu będzie pisana w JS, a część w CS (który kompiluje się do JS) i nie będzie już jedynego słusznego języka.

    •  

      pokaż komentarz

      @BeSmarter:
      @wojciechka1:
      @evapor:
      Plebs pisze po plebejsku. Profesjonaliści piszą profesjonalnie i zgodnie z zasadami inżynierii oprogramowania.

      W JS-ie plebsu jest mnóstwo -- trochę jak w PHP-ie.

      Ale coś Wam, zdaje się, umyka. Sami się zastanówcie. Co ma język do wzorców projektowych? Naprawdę niewiele. W JS-ie z powodzeniem można stosować większość wzorców projektowych. Niektóre są niepotrzebne ze względu na dynamikę języka, inne (Strategia) są wspierane nieporównywalnie lepiej niż do niedawna w Javie (która dopiero niedawno dorobiła się porządnych funkcji anonimowych).

      CoffeeScript ma ten problem, że ludzie nie rozumieją, co tak naprawdę daje. Tak, daje lepszą, ładniejszą składnie. Nie, lepsza składnia nie umożliwia stosowania nowych wzorców projektowych! To, że na najbardziej elementarnym, niemal leksykalnym poziomie, Twoja aplikacja będzie pozornie ładniejsza, nie oznacza, że ma choć trochę lepszą strukturę. CoffeeScript struktury w zasadzie nie zmienia, daje jej tylko lepsze ubranko.

      Mikrowzorce (wzorce leksykalne) nie są najciekawsze w JS-ie. Prawdziwym wzorcem projektowym jest coś większego: element struktury programu, sterowanie zachowaniem lub tworzenie obiektów.

    •  

      pokaż komentarz

      @evapor:

      Tearaz JS to ten sam język, co lata temu

      Nie, nawet na wikipedii to wiedzą.

      MVC? Po kiego grzyba, skoro JS na potencjał na V i może 1/2 C?

      No i masz różne MV*, na C nie starczyło potencjału.

      Programują ludzie, nie język, ogarnij to kiedyś, później bóldupkuj ;]

    •  

      pokaż komentarz

      @vldc: Tylko, że rozsądni ludzie jakoś tak od ponad dekady warstwę danych dla aplikacji webowych wolą trzymać po stronie serwera.

    •  

      pokaż komentarz

      @evapor: Stwierdzenie, że rozsądni ludzie przez 10 lat się nie rozwinęli nienajlepiej świadczy o Twoim rozumieniu rozsądku ;).

      Rozsądni ludzie wiedzą, co do czego służy i umieją korzystać z technologii pragmatycznie zamiast podchodzić do tematu dogmatycznie.

    •  
      a...........r

      -1

      pokaż komentarz

      @evapor: Rozsądni ludzie?
      Chyba tacy, którzy boją się javascript-u. Po stronie serwera wystarczy, że jest interfejs REST, a reszta na CDN-ie.

  •  

    pokaż komentarz

    Wykopię, bo akurat przerabiam wzorce projektowe na zajęciach i przyda mi się to do ewentualnego kolokwium :-)

    •  

      pokaż komentarz

      @PingwinPL: Czemu wszystko się wszędzie przerabia, a nie omawia/analizuje :-/ To znaczy, że nic nie zostało dobrze zrobione?

    •  

      pokaż komentarz

      @sajam: to znaczy, że na studiasz uczysz się kilogramami jakiegoś teoretycznego shitu, a proza życia wygląda i tak inaczej.

      Swoją drogą nie zawsze warto być "pro" za wszelką cenę...czasem nie mogę patrzeć na kumpli w pracy, jak tworzą jakieś skrypty gdzie 5 kB zajmuje cały szkielet wzorca projektowego, a kod który się realnie wykonuje to obsługa dwóch kliknięć pokazujących formularz na stronie ( ͡° ͜ʖ ͡°). Bo on programuje.

    •  

      pokaż komentarz

      @chybaja: Chodziło mi o gramatyczną część wypowiedzi. Niczego się nie przerabia (modyfikuje), tylko się omawia (analizuje). Lektur w szkole też nie przerabiasz, bo "są naprawdę dobrze napisane" jak zwykła rzec moja polonistka.

    •  

      pokaż komentarz

      @sajam: Ależ przerobić coś to również znaczy "zapoznać się z". Tutaj odsyłam do słownika pwn :-)

    •  

      pokaż komentarz

      @PingwinPL: Osz kurdę, racja: http://sjp.pwn.pl/slownik/2511042/przerobi%C4%87 (patrz punkt 4.). Grr, że też teraz na to zaglądam - jakbym wiedział o tym wcześniej utarł bym jej nosa :-/

    •  

      pokaż komentarz

      @chybaja:
      Widzisz wiele takich sytuacji?

      Ja obserwuję coś dokładnie odwrotnego. Żałosmy poziom inżynierii oprogramowania w JavaScripcie. Pełno amatorów. Niewiely prawdziwych profesjonalistów. O rzeczach typu SOLID mało kto słyszał, jako takie luźne powiązanie czy DRY czy to już niemal święto, a co do testów automatycznych... Cóż, to jak z seksem wczesnych nastolatków: każdy o tym co najwyżej pitoli, nikt tego nie robi.

      @PingwinPL:
      Chcesz być lepszy niż 80% kandydatów na rozmowach kwalifikacyjnych? Naucz się i ZROZUM tak z dziesięć wzorców projektowych i nie wyjeżdżaj od razu z Singletonem. To wystarczy.

      Niestety, mówię serio. A "przesłuchałem" dziesiątki programistów, większość z wieloma latami doświadczenia i informatyką skończoną na dobrej uczelni.

      Ja sam, w grupie na studiach, byłem jednym z tych nastawionych bardziej entuzjastycznie na IO, a i tak nie doceniałem, jakie to ważne, jeśli chce się być naprawdę dobrym koderem piszącym bardziej skomplikowane aplikacje.

      W samym JavaScripcie, z wzorca Obserwator korzysta się non stop (praca z GUI -- obsługa zdarzeń), wiele złożonych bibliotek udostępnia proste API stosując Fasadę, a sam język pięknie wspiera Strategię (wystarczy przekazać funkcję anonimową -- używane ciągle w programowaniu funkcyjnym, np. z metodami tablicowymi czy z jQuery) i pewną wariację Prototypu (ma dziedziczenie prototypowe -- tego też > 80% programistów nie ogarnia, bo jest inne [protsze!] niż klasyczne ).

    •  

      pokaż komentarz

      @Sh1eldeR: Właśnie jestem na Inżynierii Oprogramowania :-). Ale przede mną długa droga jeszcze, póki co przedstawiono nam całe 4 wzorce.
      I szczerze pierwsze z czym bym chyba wyjechał na rozmowie to Obserwator :-)

    •  

      pokaż komentarz

      @Sh1eldeR: A nie jest przypadkiem tak, że za JS bierze się całkiem sporo ludzi, więc i siłą rzeczy ilościowo ilość cienkich będzie niemała? Wśród piszących (korpo-)dziawę, dotnety, czy inne rory nie jest wcale lepiej. Nie oszukujmy się, 95% istniejącego software'u to programistyczny crap, czego żadna technologia (w tym metodologia pracy) nie zmieni. Co ostatecznie często i tak nie ma wpływu na sukces produktu (dawny wordpress :D, windows :D :D :D).

      Oraz nie przesadzałbym z wymaganiami odnośnie wiedzy teoretycznej. Niejeden dobrze stosuje wzorce projektowe, nie zdając sobie z tego sprawy, nie mówiąc o ich polskich nazwach ;). To jak z językiem "nieprogramowania" (ludzkim ;)): są osoby, które posługują się nim prawidłowo, nie znając wszystkich reguł nim rządzących. Nie każdy potrzebuje tak dokładnej wiedzy, żeby coś robić dobrze. Chociaż oczywiście tego typu wiedza to z pewnością konkretny bonus.

    •  

      pokaż komentarz

      @vldc: zgadzam się. Dodałbym jeszcze, że na poziom kodu JS-owego ma wpływ przenoszenie wzorców z innych języków (przeważnie backend), które są lekko mówiąc oderwane od rzeczywistości. Druga rzecz to lekceważenie samego języka, bo ma mały próg wejścia, więc nie trzeba się starać. Dużym problemem jest też przekonanie "najważniejszy jest backend, frontend ma tylko dobrze działąć".

      To są typowe postawy dla ludzi głęboko zamkniętych na wiedzę, ludzi, którzy nie powinni decydować o rozwoju oprogramowania, a jedynie wykonywać robotę klepacza formatek. Niestety często jest odwrotnie, stąd pewnie stereotyp, że JS to język słabo zaprojektowany.

    •  

      pokaż komentarz

      A nie jest przypadkiem tak, że za JS bierze się całkiem sporo ludzi, więc i siłą rzeczy ilościowo ilość cienkich będzie niemała? [...] 95% istniejącego software'u to programistyczny crap, czego żadna technologia (w tym metodologia pracy) nie zmieni.
      @vldc:
      To prawda -- to chciałem (implicite) przekazać. Co do jakości, to technologie i metodologie nie pomagają tu zbyt wiele. Trochę mogą: technologicznie, mikro-problemy można wygryć np. linterami (dla JS-a: JSHint), więc jak ktoś sobie w najlepsze zapomina o "var", to zostanie to wykryte. To są jednak bardzo proste rzeczy; absolutna podstawa, które sama w sobie jakości nie zapewnia. A maszyna nie sprawdzi nawet sensowności nazw/identyfikatorów, o strukturze logicznej nie wspominając! Metodologicznie... teoretycznie możnaby wprowadzić zasadę, że żaden kod nie wchodzi do trunka zanim nie przejdzie wymagających inspekcji kodu, robionych przez najlepszych programistów z teamu. W praktyce, paraliżowałoby to pracę, więc idzie się na ustępstwa.

      Niejeden dobrze stosuje wzorce projektowe, nie zdając sobie z tego sprawy, nie mówiąc o ich polskich nazwach ;). To jak z językiem "nieprogramowania" (ludzkim ;)): są osoby, które posługują się nim prawidłowo, nie znając wszystkich reguł nim rządzących.
      To zależy. Zgodzić się mogę, że da się być w czymś dobrym, znając to od podszewki na fundamentalnym poziomie, a nie ucząc się na pamięć rzeczy bardziej wysokopoziomowych.

      Ja np. nie potrzebowałbym wiedzieć o "module pattern" z JavaScriptu. Nie muszę się tego uczyć na pamięć, nie jest to dla mnie żadne odkrycie. Dla mnie to po prostu utworzenie zakresu ważności (za pomocą IIFE, ale równie dobrze jakiejkolwiek innej funkcji) i zwrócenie obiektu z pewnymi właściwościami (może być za pomocą literału obiektowego [formalnie nazywa się to inicjalizatorem obiektu] albo utworzenia jakiegoś obiektu i doklejania do niego własności -- sposobów jest wiele).

      Znając te fundamenty, mógłbym sam sobie dojść do "module pattern" i nie potrzebowałbym za bardzo znać jego nazwy.

      Nieco podobnie jest z normalnymi wzorcami projektowymi, a nie tylko tymi (niemal) "leksykalnymi". Jeśli ktoś znałby superdobrze fundamentalen zasady inż. opr., takiej jak zmniejszanie liczby powiązań, DRY, SOLID, to mógłby pisać naprawdę niezły kod, nie znając wzorców -- część by z pewnością niezależnie "wymyślił"!

      Ale ludzie nie znają dobrze fundamentów.

      Ile osób ryje w specyfikacji JS-a? Ile zna i stosuje te fundamentalne zasady inż. opr.?

      W JS-ie, ludzie spędzają większość czasu na spuszczaniu się nad frameworkami (zresztą: ni cholery nie rozumiejąc, jak zostały napisane). Nawet jak ktoś ma wreszcie usiąść do pisania testów, co samo w sobie jest świętem, pyta się i węszy, jakiego to frameworka użyć. Może Jasmine jest de best, bo widział fajne tutoriale? A może Mocha, bo ponoć jacyś hardcore'owcy w tym robią? A ci od jQuery mają QUnit! Jaka składnia jest najlepsza? TDD? BDD? Asercje pisać lepiej w stylu should, expect czy jsunit? Jasne, można się nad tym zastanowić i trzeba podjąć te decyzje, ale nie ma sensu zagłębiać się w nich na długie tygodnie -- widziałem sytuacje, gdzie tyle trwała rozgrzewka przed rozpoczęciem pisania testów, bo ktoś sobie kompletował stacka. A po napisaniu parunastu testów i tak olał sprawę.

      To nie ma takiego znaczenia. Dobre testy można napisać zarówno w Jasmine, jak i QUnicie. Asercje to też sprawa drugorzędna. Wcale nie byłoby aż o tyle gorzej, gdyby ktoś używał tylko assertTrue i ew. napisał sobie do tego helpery.

      Wracając jeszcze do wiedzy. Kto to powiedział? Chyba Feynman. "Jeśli nie umiesz wytłumaczyć czegoś w prosty sposób, to znaczy, że tak naprawdę tego nie rozumiesz". Dlatego ostrożny byłbym w chwaleniu programistów, którzy robią coś na ślepo i wyłącznie na czuja (elementarne i bardzo dogłębne rozumienie fundamentów to inna sprawa).

      @mroq:

      Dodałbym jeszcze, że na poziom kodu JS-owego ma wpływ przenoszenie wzorców z innych języków (przeważnie backend), które są lekko mówiąc oderwane od rzeczywistości.
      To akurat widziałem. Tworzenie (za pomocą new) obiektów-strategii, mających jedną metodę. A można było wstawić funkcję -- nazwaną lub anonimową. Ale w Javie funkcje nie są obywatelami pierwszej kategorii, więc po co wykorzystywać to, że w JS-ie są.

      Zauważyłem jednak, że ludzie, którzy stosują takie "staroświeckie", klasyczne wzorce, są łatwi do przekonania i często chętnie się uczą tego, co daje im JS gdy zobaczą, jak to ułatwia sprawę.

      Druga rzecz to lekceważenie samego języka, bo ma mały próg wejścia, więc nie trzeba się starać.
      Tak! Kupa (nie bez powodu używam tego określenia) ludzi pisze w JS-ie... nie znając JS-a. Ni cholery. Mówię tu o jego fundamentach.

      stąd pewnie stereotyp, że JS to język słabo zaprojektowany
      Cóż, Przewspaniale to on zaprojektowany też nie jest, choć starają się iść do przodu i łatać pewne luki (typeof, faworyzowanie zmiennych globalnych...). Ale ma też świetne rzeczy (funkcyjność, literały), no i został...

    •  

      pokaż komentarz

      @Sh1eldeR:

      Cóż, Przewspaniale to on zaprojektowany też nie jest, choć starają się iść do przodu i łatać pewne luki (typeof, faworyzowanie zmiennych globalnych...). Ale ma też świetne rzeczy (funkcyjność, literały), no i został...

      Bez przesady, stawiam piątala, że dowolny inny język ma porównywalną liczbę wad i zalet.

    •  

      pokaż komentarz

      @mroq:
      Myślisz, że choćby taki CoffeeScript nie jest dosyć znacząco lepszy od obecnej wersji JS-a, tj. ES5?

      Mówimy oczywiście wciąż o samym języku i jego skłądni; fakt, że CS trzeba dodatkowo kompilować nie ma znaczenia podobnie jak to, że JS przeglądarkowy cierpi z powodu niekompatybilności -- to są rzeczy praktycznie niezależne od samego projektu języka, a o tym właśnie mówimy. Naturalnie, w kontekście wzorców projektowych innych niż czysto leksykalne praktycznie nie ma znaczenia, czy używasz JS czy CS.

    •  

      pokaż komentarz

      @Sh1eldeR: Myślę, że nie jest, bo CS to nakładka na JS-a. To co się da zrobić w CS-ie można przeprowadzić natywnie w JS-ie. Nie myślałem o syntaktyce, bardziej o rzeczach, których nie jesteś w stanie wykonać przez ograniczenia języka. Szybsze i ładniejsze pisanie się do nich nie zalicza.

    •  

      pokaż komentarz

      @mroq:
      IMO syntaktyka właśnie ma znaczenie, bo w każdym jezyku kompletnym w sensie Turinga możesz zaimplementować wszystko. Nawet w Brainfucku.

      Ważne jest więc, jak wygodnie i czytelnie możesz coś zrobić. W przypadku CS-a, notacja grubej strzałki, array comprehensions, spread, rest czy let dają nowe możliwości i są na tyle przydatne, że trafiają do ES.Next. Gdyby nie ulepszały języka, to by do ES.Next nie trafiły (bo po cholerę). Należą więc do przewag, jakie ma CS nad JS-em.

    •  

      pokaż komentarz

      @Sh1eldeR: fajnie, ale mimo wszystko te same przewagi można opakować w bibliotekę i używać w czystym JS-ie. CS powstał dla ROR-owców, nie oszukujmy się.

  •  

    pokaż komentarz

    To ja dodam coś krótkiego, ale bardzo przydatnego dla początkujących, na temat wzorca modułów:
    http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html

  •  

    pokaż komentarz

    A może ktoś mi podać link do podobnej strony z wzorcami projektowymi PHP? Będę bardzo wdzięczny