Zyx, temat M w MVC to bagno.

Zauważ, że wiodące frameworki (nie tylko w PHP, mówię np. o RoR) są mocno zorientowane na Database Driven Development i rolę modelu pełni najczęściej jakiś rodzaj ORM. Robi to furorę, ale jednocześnie sprawia, że programiści zapominają (albo gorzej - nigdy się nawet nie dowiadują) o modelowaniu własnych obiektów - modeli dziedzinowych.

Nie wiem kiedy nastąpił ten podział, ale najczęściej jest on nie do przeskoczenia.

@LBO: a w jakim zakresie projektowanie własnego modelu jest sprzeczne z wykorzystaniem istniejącego ORM? Przecież ORM to tylko nakładka która pozwala uzyskać perzystencję - nic innego nie dodaje/nie zmienia.

ORM to tylko Object-relational mapping, czyli w uproszczeniu mapowanie obiektu na pola bazy danych. Programujemy obiektowo prawda? Każda cegiełka naszej aplikacji to obiekt, cegiełki tworzą ściankę która de facto też jest obiektem. I najlepsze co może być, moim zdaniem, to budowanie modelu właśnie w oparciu o te cegiełki-obiekty. Więcej, każdy model to powinna być osobna cegiełka. Widok zaś to to, co wybiera w zależności do potrzeb (Http Request) model(lub modele, w zależności od komplikacji aplikacji jaki i requesta) i bardzo prosto przekazuje(w sumie samym przekazaniem zajmuje się kontroler) to do szablonu(szablonem może być HTML, XML czy CVS) i np. sortuje po dacie, czy czymkolwiek chcesz. A resztą, całą obsługa zajmuje się kontroler.

Ja nie rozumiem gdzie macie bagno w modelu czy widoku? Rozbijasz daną stronę na poszczególne elementy; stałe, niezmienne elementy pakujesz do szablonu; zmienne, pakujesz do Bazy/ORM/Obiektu/Modelu. Widok wybiera z modeli tylko te potrzebne akurat teraz i zajmuje się podstawową obróbką/sortowaniem a reszta bagna jest w kontrolerze.

___________
PS. Być może was do końca nie zrozumiałem, być może wy mnie nie rozumiecie. Być może niepotrzebnie piszę o rzezach oczywistych, być może wydaje mi się tylko że widzę wszystko krystalicznie czysto przez tą butelkę ginu.

A ja właśnie uważam zupełnie inaczej.
Obiekty służa ładnym uporządkowaniu pewnych funkcjonalności i przejrzystość w korzystaniu z pewnych elementów lecz z ich wykorzystaniem nie przesadzajmy. Nie wszystko musi być obiektem i skoro NIE MUSI nim być to lepiej użyć prostszych i mniej zasobożernych rozwiązań. Obiekt zajmuje znacznie więcej miejsca w pamięci i jeżeli jego użycie nie przyniesie większych korzyści niż zaoszczędzenie sobie jednej linijki kodu to wolę użyć tablicę.

Weźmy chociażby dekoratory w Zend_Form. Noż nie wiem kto coś takiego wymyślił, że każda pierdoła zwykły tag musi być obiektem. W dużym formularzu robi się tych obiektów multum (i multum zapchanej pamięci). A czy nie można było tego zrobić prościej? Chociażby wyświetlanie pojedynczego elementu powierzyć jednemu plikowi szablonu? Ile by się przy tym zaoszczędziło czasu programisty i zasoby serwera.

Weźmy kolejny przykład. Nienawidze nie ścierpie "Mądrego" podejścia większości zendowców. Przesadzają z wykorzystaniem kupy narzędzi, które tak naprawdę są bardzo mało (a czasem nawet wcale) potrzebne.
Przykład. Zastępując require_once metodą Zend_Loader::loadClass . No to cholere? Po co ładować taka banalną rzecz w coś co zrobi to samo tylko, że wolniej (znacznie) oraz żadnej super funkcjonalności nie przynosi. Niedługo dojdzie do tego, że echo zastąpią jakąś klasą.

Najśmieszniejsza rzecz z jaką się spotkałem w świecie zendowców to... żeby usunąć rekord należy go pobrać i dopiero usunąć??

Kolejny kwiatek (nie wiem czy da się to wyłączyć czy też nie, zresztą już mnie to nie interesuje). Po kiego do Zend_Db_Table_Row wrzucany jest mi schemat całej tabeli z szeroką gamą informacji o danej kolumnie? Jak będe potrzebował to sobie sam te informacje pobiore. Koszt jaki tym ponosze? Kolejne marnotrawienie pamięci. O ile da się to w pewien sposób wyłączyć (rozszerzając tą klasę) to i tak klasa rodzica zostaje w pamięci marnotrawiąc kolejne zasoby.

Czy takie marnotrawienie pamięci rzeczywiście jest złe? Oczywiście. Pewnego razu tworzyłem serwis, który posiada dużą ilość osób online na raz (1500), oraz mnóstwo wywołań ajaxowych. Przepisałem cały serwis na super mini mvc. Były m.in takie obiekty (baza danych, obsługa urla, session_handler, kontroler (abstract)) i co? Padło w pierwszym dniu. Trzeba było przywrócić starą wersję i trochę ją posprzątać. Gdzie było zmarnotrawienie pamięci i czasu procesora? A no sparsowanie urla, znalezienie i zainicjowanie kontrolera nie jest tak naprawdę bardzo konieczne (można przecież nawet na potrzeby jednego serwisu potworzyć pare plików .php które parsowanie urla nam oszczędzą (wiadomo nie wszędzie da się tak zrobić) a kontroler też nie jest tak do końca konieczny. Każda taka pierdoła ma ogromne znaczenie przy dużych serwisach, a i przy małych na jednym serwerze potrafi dać pewne oznaki swojej obecności. O ile w podanym przeze mnie przypadku taka pierdoła jest naprawdę mała to już wolę sobie nie wyobrazić jak wielkim wąskim gardłem jest duża ilość rozwiązań z zenda.

Dlatego tak bardzo jest ważne rozsądne korzystanie z obiektowości i nie robienie wielkiego śmietnika, który potrafi dużo ale też bardzo dużo może nas kosztować. I jeżeli, ktoś mówi "autorski FW pewnie nie umie tyle co taki (ten ten a ten i tutaj szeroka lista)" to jest to żaden argument. Ale DOBRZE, że właśnie ten autorski FW nie umie tyle, ale za to ma tyle ile potrzebuje i nie wali kupy w pamięci jeżeli nie jest to konieczne.

Stosować jak najbardziej należy, bo to jest wygodne. Ale modele - odzwierciedlające zachowanie systemu - budować osobno i ewentualnie wewnątrz bawić się ORMem. Albo budować ORM na interfejsach (abstraktach) wymodelowanych pod system.
Ważne, by na jakimś poziomie działania modele były niezależne od źródła danych.

~wookieb, a już myślałem że sam na tym świecie z takim podejściem zostałem.

Mnie też właśnie ZF denerwuje takim podejściem; niedługo pird programisty będzie obiektem i to jeszcze z takimi własnościami, że głowa mała. Tylko pozostaje jeszcze druga kwestia większości - dołoży się kostkę RAM i będzie po problemie. Takim ludziom nie przetłumaczy, że gdyby się nieco sprężyli, to by i na współdzielonym pozostało.

Trzeba wypośrodkować, bo gdy całkowicie porzucić obiektówkę - bałagan, za dużo obiektów - problemy z zasobami.


ORM są osobną kwestią; można powiedzieć, że to najwęższe gardło współczesnych aplikacji opartych na MVC (i nie tylko zresztą). Właściwie, to większość aplikacji wcale ORM nie potrzebuje, gdyż są to jedynie generatory zapytań upchnięte w dziesiątki klas, autoloaderów i innego badziewia, które istnieje tylko po to, aby wygenerować zapytanie przez chaining obiektu i zmapować to do getterów/setterów, które dodatkowo obciążają serwis (is_callable oraz sprawdzenie, czy przypadkiem metoda już nie istnieje). A SPL z ArrayAccess jest takie fajne i leciutkie. ;]

Szczerze? Ja tam jakoś nigdy do wbudowanych ORM nie miałem przekonania Zawsze piszę swoje własne metody w modelach do obsługi konkretnych rozwiązań. Pracuję niby w Kohanie, mam do wyboru choćby QueryBuildera dla baz... a piszę "gołe" zapytania lub implementuję własne rozwiązania dla XML lub plików ogólnie w oparciu o podstawowe funkcje i sporadycznie jakieś helpery, często zresztą napisane samemu. Może to swego rodzaju "zboczenie zawodowe", ale osobiście wolę widzieć całe zapytanie jako "plain text", a nie jako łańcuchy wywołań kolejnych metod z określonymi parametrami
Obiektówka jest do modelowania problemu, a nie do wpychania jej gdzie popadnie Już niedługo dojdzie chyba do sytuacji, że to co kiedyś (przy rozsądnym użyciu) było własnością klasy zostanie klasa wewnętrzną z X własnościami swoimi i metodami na zmianę wraz z możliwością przeciążenia Jeszcze trochę i zaczniemy chodzić do kibla nie tylko by usunąć kilka obiektów klasy Kał, dziedziczących po Ekstrementy, ale będziemy mieli w tej pierwszej jeszcze jakieś bliżej nieokreślone wewnętrzne klasy pomocnicze, które pozwolą określić bakteryjną florę jelit oraz to co spożywano

Ja akurat należę do tej grupy, która bez wahania sięga po dodatkową kostkę pamięci. Skoro coś co zostało napisane i ma mi znacznie ułatwić pracę, to nie widzę powodu, by na nowo koło wymyślać. Oczywiście nie twierdzę, że wszystkie rozwiązania zastosowane w ZF są najlepsze ze wszystkich możliwych, jednak mówienie, że ZF to badziew, bo wszystko jest obiektem oznacza, że nie wie się czym tak na prawdę jest programowanie obiektowe. Podobne stwierdzenie można odnieść do DirectX. Po co mam kupować nowy sprzęt, skoro na starym działa wersja 7? Trochę poobcinam detale w grach, niektórych w ogóle nie zainstaluję, ale i tak będę mógł sobie pograć. No i nie zapominajmy, że każdy kombajn wymaga odpowiedniego sprzętu do jego uruchomienia. Przecież w ZF nie pisze się aplikacji "hello world", a wydajność projektu (czy to opartego na ZF, czy na własnych rozwiązaniach) w znacznej mierze zależy od programisty i jego umiejętności. We wszystkim można stworzyć bagno, które będzie wymagało masy zasobów.

Dlaczego ZF jest taki zamulający? Dlaczego tak popularne ostatnimi czasy ORM i MVC są takie zamulające? Ponieważ PHP jest naprawdę badziewne. Porównując PHP do przeglądarek, można śmiało stwierdzić, że PHP jest w chwili obecnej na poziomie IE6.

Gdyby tak wszyscy mówili to żylibyśmy jak lemingi albo zwierzaki oparte na instynkcie i nie rozwijalibyśmy się. Poza tym weź pod uwagę możliwość własnego rozwoju.


Brzmi jak argument Appleowców w odpowiednim temacie. Przeczytaj jeszcze raz mój post wyżej.


Tylko, że directx jest nastawiony na możliwość uzyskiwania coraz to nowszych i realistycznych efektach co przy złożoności fizyki samo w sobie wymaga większej moce obliczeniowej choć wiele rzeczy udało się zoptymalizować np przez oszukanie zmysłów człowieka.


Dlatego nie wybieram bagna, gdy mogę coś zrobić na lądzie.


Wiesz, że dobrze skonfigurowany php z akceleratorem bardzo niewiele ustępuje wydajnością Pythonowi? (któremu wróżę raczej dobrą przyszłość)

Gdyby wszyscy ciągle optymalizowali, to nie wyszlibyśmy z epoki kart perforowanych, ponieważ zawsze możnaby coś przyspieszyć bez konieczności modyfikacji sprzętu. Właśnie dlatego, że jestem w stanie nauczyć się korzystać z nowych narzędzi, rozwijam się. Przecież mogłem zostać na 386 i pisać w Tigu, Tagu i zamiast graficznych narzędzi używać wiersza poleceń - przecież jest wydajnieszy...

Raczej brzmi jak argument osoby, która wie co to jest programowanie oniektowe nie z wikipedii, a z doświadczenia.

Mam okazję pamiętać czasy, w których programiści walczyli na programy w asemblerze. Walka ta polegała na napisaniu najszybszego algorytmu rysującego piksel na ekranie. Przyszedł DirectX i zepsuł całą zabawę. Tak samo jest z frameworkami. Jest to naturalny rozwój danego języka, polegający na dodawaniu kolejnej warstwy abstrakcji, która siłą rzeczy wymaga mocniejszego sprzętu. Tak samo jak przesiadka z notatnika na Eclipse.

Jeśli pisanie aplikacji w "czystym" PHP nazywasz "na lądzie", to sądzę, że szybko skończy się ta dyskusja.

PHP jest badziewny nie ze względu na wydajność, ale na burdel jaki w nim panuje i wiele innych rzeczy, o których już nie raz pisałem i nie chce mi się tego znowu powtarzać. Uprzedzając kolejne pytanie - programuję w PHP, ponieważ popełniłem błąd w wyborze technologii, w której chciałem się specjalizować.

Nie wspominałem o tym, że mamy się hamować albo nie korzystać z rozwiązań ułatwiających życie. Cały czas wspominam o rozsądnym podejściu do wykorzystania "udogodnień" dla programisty, które tak naprawdę czasem nie są potrzebne. Wszyscy ciągle coś optymalizują. Gdyby nie chęć optymalizacji komputerów to nie mielibyśmy dziś laptopów. Elektronicy mogą tutaj dużo powiedzieć na temat rozwoju tej dziedziny techniki w dziejach historii.

Oczywiście, że tak. Ale tutaj arena walki odbywa się na innej dziedzinie. Parę linijek kodu więcej dla ciebia = więcej osób pomieścisz na serwerze. Jak wyżej wspomniałem nie mówię, że programowanie obiektowe jest be. Jest jak najbardziej prawidłowym podejściem pod warunkiem, że się z nimi nie przesadzi.



Ja niestety też dlatego przechodzę na ActionScripta, który ciekawi mnie znacznie bardziej niż bawienie się z htmlem i bazami danych.
W dodatku przy tworzeniu efektów wizualnych rzeczywiście można popisać się swoimi umiejętnościami.

Przychylę się do tego co mówi wookieb i co być może łatwo wyczytać z mojego poprzedniego postu: wszystko jest dla ludzi, ale nie należy z niczym przesadzać. Wookie i ja mieliśmy na forum niedawno tutaj zabawę z optymalizacją algorytmu i szczerze mówiąc bawiłem sie dobrze zmuszając szare komórki do pracy inaczej niż "Kurcze... Jaka funkcja we frameworku robiła to wszystko za mnie?" A do tego właśnie wszystkie dążą z ZF na czele: "Poznaj moje funkcje, które być może robią to samo co te z manuala, ale są obiektowe, więc bardziej cool". Jak dla mnie by naprawdę zrozumieć język i móc się nim wprawnie posługiwać, trzeba znać jego podstawy i nie skakać od razu na framework, bo inaczej później będą problemy nawet z prostymi rzeczami.

Obiektówka jest fajna i ułatwia wiele rzeczy, gdyż modeluje zachowania świata rzeczywistego i pozwala to odwzorować na język komputerowy. Tyle że nie warto wszystkiego sprowadzać do roli abstrakcyjnego obiektu. Poza tym to własnie optymalizacja pozwala nieraz na skoki technologiczne. Wprowadziłeś przykład Directów... Znasz więc jak mniemam tematykę i wiesz że tak mocno zoptymalizowano wydajność antyaliasingu między wersjami 9.0c, 10.0 i 10.1 że jest o kilkadziesiąt procent szybszy. Sam na studiach w assemblerze pisałem wstawki i nie uważałem tego za przyjemność. Niby instrukcji mało (na nowych prockach liczba jest duża, ale też ich sens jak dla mnie nieraz wątpliwy ), ale wygoda pisania niemal zerowa. Poza tym dobre kompilatory i tak kod maszynowy na tyle zoptymalizują, że będzie niewiele wolniejszy od assemblera.

Co do wprowadzania kolejnych "warstw abstrakcji" to przy takim podejściu do sprawy niedługo do włączenia notatnika będzie potrzebny procesor 2GHz i 1GB RAM Bo od poziomu sprzętu do poziomu aplikacji nie tylko przejdziemy cały model OSI/ISO, ale jeszcze zahaczymy o kilkanaście protokołów, maszyn wirtualnych, aplikacji konwertujących i ki czort wie czym nas jeszcze uraczą w każdej z warstw modelu. Sorry, ale dla mnie wszystko co jest po drodze tylko dlatego, że ktoś sobie tak wymyślił, choć jest to po prostu marnowanie zasobów, jest zbędne. Jeśli jest użyteczne to rozumiem, że się przyjmie. Ale jeśli muszę coś opanować/uzyć tylko dlatego, że tak musi być i nikomu nie jest tak naprawdę potrzebne to ja się pytam, gdzie tu logika?

Co do OP i OOP oraz definicji doświadczeniowo-wikipedystycznej to wałkowanie i poznawanie od wielu lat takich języków jak Java czy C++ a także wbijanie mi tego do głowy przez wykładowców (gdy to pisze jestem już absolwentem od kilku lat) podczas studiów (na kilkunastu przedmiotach związanych z programowaniem i tworzeniem projektów) myślę, że nie sprawiło bym błędnie rozumiał tę dziedzinę. A jeśli już jesteśmy przy tym dlaczego zajęliśmy się PHP, to u mnie odpowiedź jest prosta. Bo taką miałem zachciankę Interesowałem się internetem i naturalnym było, że zacząłem od html by stopniowo inne poznawać. Tu trochę JS, tam liznąć CSS, potem przyszedł PHP i bazy danych. Z czasem zapewne zostanie to poszerzone o kolejne technologie webowe (jeśli będzie czas na coś innego poza rodziną i pracą).

I rozumiem podejście określone przez wookiego "bagnem", a przynajmniej wydaje mi się że tak jest. Najprościej rzecz ujmując. Po co mi scyzoryk szwajcarskiej armii z X końcówkami, dodatkami, z którym trzeba uważać by nie zniszczyć za prędko, skoro mogę mieć zwykły nóż myśliwski, którym mogę rzucać, skakać po nim itp i jestem pewny, że idealnie się do moich potrzeb nada. A wiele frameworków to takie scyzoryki, których pełnych możliwości się po prostu nie używa, ograniczając jedynie do pewnych podstawowych. Czy jest więc sens ich stosowania? Nie lepiej okroić z możliwości lub znaleźć ów nóż dostosowany do naszych określonych potrzeb?

Co do OOPWiem co miałeś na myśli, ale powinieneś to doprecyzować, bo przy powyższym to Java i inne podobne "przeginają". W PHP np. nie warto czasami korzystać z obiektów, bo (jak zauważyli przedmówcy) bo daje ono narzędzia (np. w postaci tablic asocjacyjnych), które są szybsze - a dają podobne możliwości (oczywiście: w niektórych przypadkach)

I nie ma w tym nic złego pod warunkiem, że ten 1GB to będzie powiedzmy jakaś jedna stutysięczna część dostępnej na PC pamięci. Jeżeli postęp technologiczny pozwala na pewne marnotrawstwo pamięci, mocy obliczeniowej czy zużycia energii (no, z tym to jeszcze dłuuugie lata będzie przynajmniej u nas spory problem :]) to "czemu nie"?

Oj Panowie, Panowie...

W ostatnich paru postach utworzyliście dwa fronty, które Seth opisał w fajnym poście na blogu.

To są po prostu dwa skrajne bieguny; artyści i pragmatycy. Można oczywiście wszystko pakować w tablice, wszystko w jakieś zmienne lokalne i zrobić tak, żeby działało od zaraz jak najszybciej ale wtedy zaczynają się schody kiedy trzeba zaopiekować się systemem (Tablice). Można też dorobić do każdego elementu mały framework, doprowadzić system do granic elastyczności i modularności (wszystko obiekt) ale za to system produkował by się o powiedzmy 500% dłużej niż powinien.
W przypadku obu podejść trzeba wyczuć złoty środek, aby pogodzić modularność z prędkością pisania aplikacji. Tu przychodzi doświadczenie programisty/projektanta który potrafi wyczuć które elementy systemu będą często zmieniane, rozszerzane a które mniej i odpowiednie podejście zastosować do każdej części.

W przypadku ZF to ich podejście jest jak najbardziej zrozumiałe. To jest framework dla mas. Każdy używa go w inny sposób i do czegoś innego. Jest takie zróżnicowanie potrzeb, że jednak najzdrowszym podejściem jest podejście "artysty". Z kolei jakbyśmy chcieli napisać prosty kalkulator, to bez sensu byłoby dorabiać do niego cały framework matematyczny - a nóż ktoś zechce na nim liczyć liczby zespolone.

Odniosę się też do małego starcia pomiędzy Batmanem i Wookieb. To że jest coś obiektowo napisane, w pełni obiektowo, nie znaczy, że musi być niewydajne albo mało wydajne... i:
Nie znoszę takiego podejścia

Java to nie jest OOP tylko OP. Przyjrzyj się architekturze tego języka. Tam najmniejszą elementarną częścią jest klasa Object, po której dziedziczy wszystko.Wszystkie dane są obiektem i jest on domyślnym typem, a wszystko może być do niego przekształcone. Rozumiem za to sens zastosowania maszyny wirtualnej w ich wypadku. To warstwa pośrednicząca między systemem a aplikacją, mająca uniezależnić ją od niego. Takie podejście jest akceptowalne dla mnie i wielu osób. To samo podejście zastosowano choćby w OpenGL, gdzie operacje graficzne są tłumaczone pomiędzy kartą graficzną a kodem także niezależnie. I stąd uważam to za lepsze od DirectX, bo daje takie same lub lepsze rezultaty nie na jednym, ale kilku systemach operacyjnych. Zresztą jeśli przyjrzysz się protokołom internetowym to zauważysz, że rozwiązania różnych firm nieraz łączyły 2 i 3 warstwę modelu OSI/ISO w jedną, czyli był przypadek odwrotny do tutaj omawianego.
Niestety jeszcze długie lata poczekamy zanim nastąp skok technologiczny. W chwili obecnej doszliśmy już niemal do granicy możliwości zmniejszania układów krzemowych i każda próba dalszego zmniejszania sprawia, że procesory, z uwagi na przeskoki elektronów, popełniają coraz więcej błędów. To dlatego wprowadza się kolejne rdzenie by dotrzymać prawu Moore'a. Jeśli nie można zmniejszać fizycznie układu to należy go dublować. Dopiero wprowadzenie nanotechnologii (nanorurki węglowe), oparcie o struktury DNA będzie przełomem pozwalającym na dalsze, bezpieczne zmniejszanie układów.
Osobiście nie wiem do kogo mi bliżej w podejściu... Lubię gdy kod jest szybki, ale cenię swój czas i wygodę pisania. Potrafię pójść na kompromis między estetyką kodu i jego funkcjonalnością a wydajnością. To co mnie irytuje jednak to podejście do obiektowego programowania przez niektórych. Gdyby mogli to wystawili by mu ołtarzyk i modlili się do niego. Według nich optymalizacja jest zbędna, bo twórcy już się tym zajęli wypuszczając narzędzie. Mają rację, ale to jest optymalizacja na poziomie funkcjonalności obiektu i tylko trochę tyczy wydajności, na tyle, na ile nie zaburza jego elastyczności i skalowalności.Tym zapatrzonym we framework nawet nie przyjdzie do głowy próba napisania własnej metody w kodzie, mimo że byłaby ileś razy szybsza, bo twierdzą, że to rozwiązanie już framework udostępnia i nie chcą wymyślać koła na nowo. Tyle że nie zauważają, iż dane rozwiązanie ma ogromny czasem narzut wynikający z przyjętych przez piszącego konwencji i zastosowanych rozwiązań oraz podejścia. Z biegiem czasu dojdzie do sytuacji, że programiści znają tylko funkcje frameworka, który zastąpi im wszystkie z danego języka, ale przepisane do niego wolę nie wiedzieć jak wtedy się wszystko będzie ślimaczyć, gdyż dojdzie cała warstwa przepisująca funkcje frameworka na kod języka, a do tego obiektowo. Co z tego, że ktoś będzie miał certyfikat twórcy frameworka, skoro tylko do niego będzie ograniczony podczas tworzenia aplikacji?

Wspomniano o wojnie: artyści i pragmatycy. Nie wiem jak Ty nasty to widzisz, ale jak dla mnie nie tak definiuję te terminy. Pragmatyk to osoba, która ma ograniczone spojrzenie na język, korzystająca z utartych rozwiązań i algorytmów byle osiągnąć zamierzony efekt szybko i z w miarę dobrą wydajnością. Wynika to z ilości napisanego kodu i dostrzegania gdzie jaki algorytm nada się najlepiej. Artysta jest jego rozwinięciem. Potrafi zmodyfikować algorytmy już przez innych napisane, nie boi się stosować własnych, autorskich i często trudno zrozumiałych dla pragmatyków, którzy dopiero po bliższym się przyjrzeniu im zauważają dopiero zalety takich konstrukcji. Powiedziałbym, że artysta to pragmatyk, który zrobił lvl-up w postrzeganiu programowania Wyszedł poza ogólne przyjęte schematy i jest na tyle dobry, że potrafi sam tworzyć nowe.
Wielu zaś uważa za artystów tych, którzy piszą kod szybko i mało wydajnie ale korzystając z gotowych narzędzi z funkcjami, które sprawiają, że nie muszą się oni przejmować kilkoma płaszczyznami działalności programu skupiając tylko na jednej lub dwóch. dla takich pragmatyk, to ten który grzebie się w kodzie "o jeden poziom abstrakcji niżej". Gdyby tak skrócić mój sposób postrzegania do kilku słów to można to określić jako:
Pragmatyk - doświadczony programista określonego języka,
Artysta - doświadczony programista wielojęzykowy.

EDIT: Temat fajny bo można się szerzej wypowiedzieć i jak widzę piszą tutaj raczej osoby w sposób rozsądny, bez flame'a, z bogatym doświadczeniem w języku. Byle więcej takich tematów z sensownymi wypowiedziami było w przyszłości Nawet to, że nie zgadzamy się we wszystkim nie prowadzi do bezsensownych utarczek ale raczej konstruktywnej krytyki określonego podejścia.

thek, nie o to mi chodziło
Tu nie chodzi o skille programistyczne w różnicy pomiędzy "artystą" a "pragmatykiem" a o warunki projektu; Ile mamy na niego czasu, jakie są wymagania niefunkcjonalne odnośnie skalowalności, modularności itd..

Bo pisać wszystko na nowo to też żadna sztuka. Żadną sztuką jest też pisać tak byle działało. Temu też wspomniałem o zlotym środku, który różny się z projektu na projekt i duży wpływ na wyznaczenie tego środku ma doświadczenie programisty. Bo czasem najmądrzejszym rozwiązaniem byłoby napisanie wszystkiego po najmniejszej linii oporu a czasem dokładnie rozplanować.

Dla przykładu:
Kiedyś klient mnie poprosił, żebym napisał mu bota, który na podstawie katalogów i ich zawartości tworzył pewne struktury danych i zapisywał je w bazie danych. W takim przypadku, poszedłem po najmniejszej linii oporu, napisałem wszystko w jednej metodzie (dosłownie - cały bot w main() a miał około 500 linii). Dlaczego? dlatego, że to jest małe narzędzie które będzie wykorzystywane raz na jakiś czas i to raczej jej funkcjonalność się nie zmieni. Głupim pomysłem byłoby dorabiać cały zestaw klas pod nią. Ten bot działa u klienta już bodajże drugi rok, bez zmian i bez żadnych problemów. Czy takie podejście jakie zastosowałem świadczy o moim ograniczonym spojrzeniu które nie wychodzi po za utarte szlaki czy o tym, że użyłem odpowiedniego sposobu/narzędzia do podzielonego zadania?

Dlatego uważam, że nie zawsze najlepszym pomysłem jest "dobrze zaprojektowana" aplikacja. Nie zawsze jest potrzebny taki dobry projekt systemu. Weź sobie za przykład to, że czasem stosuję się celową de-normalizację bazy danych w celach praktycznych/wydajnościowych.

Nie Takich nazywa się amatorami

Wcale nie twierdzę, że Twoje rozwiązanie jest/było złe. To co opisałeś jest w końcu tylko(?) programem specjalistycznym, od którego nie wymaga się by tańczył i śpiewał Czytałem wpis Seth-a, o jakim wspomniałeś w poprzednim poście. Gdyby spojrzeć pod tym kątem to pewnie jestem gdzieś po środku, ale bliżej mi do pragmatyka. Uważam, że najprostsze rozwiązania z reguły sprawdzają się najlepiej i są najmniej zawodne. Może to efekt tego jak nauczali mnie na studiach, a brzmiącego: "Dopóki kod nie działa to nie cuduj. Co z tego, że założenia projektowe masz poprawne, skoro nic nie działa w praktyce? Jeśli już działa jak zaplanowałeś to dopiero wtedy zajmij się rozbudową o dodatkowe funkcje. Ale by się nie motać poświęć trochę czasu na analizę funkcjonalności i tego co tak naprawdę potrzebujesz." Dlatego w chwili obecnej jestem w stanie tydzień lub dłużej siedzieć przy większym projekcie i analizować konieczne funkcjonalności, tworzyć diagramy klas, przypadków i całą tę otoczkę projektową by potem, mając już świadomość pełną jak mój projekt ma wyglądać i czym zajmować, przejść do kodowania tego we właściwym języku. I zawsze wtedy zaczynam od szkieletu aplikacji. Gdy on działa to zajmuję kolejnym "modułem". Moją największą "bolączką" i tym co mniej podoba się choćby szefowi jest fakt, że w takim podejściu coś takiego jak GUI to najmniej istotny element, który zostawiłbym na koniec. A niestety szef woli "widzieć" rozplanowanie modułów aplikacji, choć nawet mogą one w trakcie projektowania wylecieć z jakiejś przyczyny.

Całkowicie się z Tobą zgadzam. Nie można popadać ze skraności w skrajność.

A ja zdobyłem kolejnego klienta, ponieważ zamiast bawić się zadania z algorytmiki, oddałem projekt na długo przed konćem terminu i zostałem polecony innej osobie.

Dlatego trzeba podchodzić do wszystkiego z pewnym dystansem, by być w stanie zdać sobie sprawę z ewentualnych wad konkretnego rozwiązania. Ja w taki sposób podchodzę do większości zagadnień i jestem w stanie w miarę obiektywnie ocenić, czy dane rozwiązanie spełni swoja role.

Podstawą nauki dowolnego frameworka/biblioteki powinna być znajomość języka, w którym mamy zamiar wykorzystać gotowe rozwiązanie. Tutaj nie ma żadnych wątpliwości.

W PHP nie warto. Ale, jak wiesz, są inne języki, w których nie ma czegoś takiego jak programowanie strukturalne.


A co powiesz o płytach cd, potem dvd, a obecnie blue-ray? Technologia poszła do przodu i film, który kiedyś "ważył" 700MB, teraz potrafi osiągnąć kilkanaście GB. Tylko, ze w chwili obecnej kupno dysku 1TB nie jest wydatkiem rujnującym domowy budżet. Tak samo jest z innym sprzętem. Skoro mogę dokupić dodatkowa kość pamięci za 500 zł, albo spędzić miesiąc nad optymalizacja, która przyniesie mi 0.2 s, to wole kupić pamięć.

O tym pisałem wcześniej. Nie ma sensu strzelać z armaty do wróbla. Pisanie wizytówki/strony domowej na kombajnie jest co najmniej głupie.

Podobnie jak w innych dyskusjach tego typu zapomina się o jednym bardzo ważnym elemencie - kliencie.
Jak sądzicie, co wybierze klient? Przesunięcie terminu oddania projektu o kilka miesięcy, ponieważ trzeba porobić testy wydajnościowe, zamienić wszystkie cudzysłowowy na apostrofy i wykonać inne mniej lub bardziej sensowne prace (co tak nawiasem mówiąc, nie obchodzi klienta), czy dokupić pamięć/procka?
Jeśli koszt zakupu nie będzie jakiś astronomiczny, a my wyjaśnimy klientowi wszystkie za i przeciw obu rozwiązań, to 90% klientów wybierze drugie rozwiązanie.

Kolejną bardzo ważną rzeczą jest to, że zastosowanie jakiegoś rozwiązania, wymaga od programisty jego znajomości. Ktoś kto nie zna wywołanego do tablicy ZF, może stworzyć potwora, który zarżnie każdą maszynę. Równie dobrze, nie korzystając z żadnego frameworka, można napisać w czystym PHP taki kod, który również zarżnie serwer.

Jeszcze żeby rzeczywistość była taka piękna, jak mówisz... Z tego, co obserwuję, to jest dokładnie na odwrót - pseudokoderzy zaczynają od poznawania FW zamiast języka. I potem wychodzą kwiatki, jakie wychodzą - brak samodzielnego myślenia i kupa obiektów do zwykłego hello world


Ok, ale zwróć uwagę na pewną stagnację - gdyby było jak mówisz, to dawno IE6 by nie było na rynku. Sam doskonale wiesz, jak technologie idą naprzód, jak jest z teorią, a jak jest z praktyką.


Ekhm, piszesz dla każdego serwisu biblioteki z osobna? A co z DRY?


Ale zawsze jest jakiś narzut, niezależny od programisty. Choćby Propel/Doctrine; już wiele głosów się odezwało, że to jest jedno z najwęższych gardeł w całej aplikacji.

Widzę, Panowie, że temat zszedł już na poziom projektowania aplikacji

Ostatnio na blogu Sławka Sobótki czytałem pewną recenzję pewnej prezentacji Erica Evansa na temat projektowania, pozwolę sobie zacytować pewien kawałek:

"System jako całość nie może być dobrze przemyślany i zaprojektowany. KROPKA.
Nigdy nie będzie dostatecznie dużo: czasu, pieniędzy, wiedzy biznesowej, ludzi z odpowiednimi kwalifikacjami, czasu, pieniędzy, czasu, pieniędzy, czasu, pieniędzy..." (cały wpis TUTAJ)

Podpisuję się pod tym obiema rękami. Nie można przewidzieć wszystkich zależności. Dlatego też jestem wyrozumiale nastawiony do rozwiązań w których trzeba używać zwykłych tablic zamiast twórczych obiektów, czy to ze względów optymalizacyjnych, czy też projektowych.

Co do samego ZF to jest to bardzo elastyczny FW. Można z niego wyciągnąć tylko potrzebne moduły. Sam Zend_Form jest stworzony pod kątem dalszej rozbudowy, dlatego nawet najmiejszy element jest napisany obiektowo. Widzę też, że twórcy czerpią dużo z javowych rozwiązań, osobiście uważam to za plus.

Niestety. ALe na szczęście są klienci, którzy trzymają się od takich ludzi z dala.

I o tym właśnie pisałem - zapomniałeś o kliencie. To, że IE6 jest cały czas na rynku, wynika tylko i wyłącznie z wyboru/przymusu klienta.

DRY ma się dobrze Należy jednak pamiętać, że rzadko kiedy pisze się dwa identyczne projekty. Zazwyczaj korzysta się z różnej konfiguracji bibliotek/sprzętu.

Narzut jest już w momencie użycia funkcji *_connect. Co nie zmienia faktu, że każda dodatkowa warstwa abstrakcji wprowadza pewne opóźnienia.

Takie rozwiązanie z dokupowaniem pamięci może być, ale tylko jeśli sam sobie stawiasz serwer lub rozwiązanie jest "na local", nie zaś gdy tworzysz mające iść na serwer współdzielony. A klientowi robi różnicę gdy musiałby zamiast niego wykupić dedyk, którego cena za miesiąc jest podobna do opłaty za rok na współdzielonym. Nie każdy wtedy taki chętny już będzie.

Jeśli już wskoczyliśmy na temat filmów to jest wyraźna różnica pomiędzy każdym ze wspomnianych. Począwszy od rozdzielczości kończąc na jakości i zastosowanych kodekach. VCD to nie DVD z domyślnym mpeg-2 i na pewno nie to co na dysku Blu-Ray. Tutaj nie ma co porównywać nawet. Nie chodzi już nawet o technologię, bo pomiędzy CD a DVD różnica w zasadzie z grubsza jest tylko w laserze i gęstości zapisu. W zasadzie to można porównać jedynie do zmienionego kodeka. Wiadomo, że i tak nie otrzyma się "żylety" bo to musiałoby być związane z bezstratnym kodowaniem materiału w RGB. A to są koszmarne ilości, gdyż sam robię czasem niekompresowane zrzuty z karty graficznej i przykładowo materiał 1280x800 trwający 65 sekund to już 993MB a utkniemy oczywiście na limicie obsługi pamięci choćby w starszych systemach i powyżej 4GB się plik "wysypie". A co dopiero mówić o całym 90 minutowym filmie. Blu-Ray mógłby się pokusić powoli o coś takiego, ale i tak musiałby mieć jakiś bezstratny kodek i być dzielony na małe pakiety.

Co do IE6 to wynika jego pozycja w dużej mierze z musu i pewnego "przywiązania". Na szczęście jest wiele dobrych alternatyw i ciągłe tłuczenie do głowy daje jakieś rezultaty. Wolno, ale jednak sie zmienia układ na rynku co może tylko cieszyć. Niestety IE nawet w tej samej wersji jest nieprzewidywalny. Przykład miałem wczoraj. Klient dzwonił, że mu się nie wyświetla coś na stronie. Odpaliłem na 4 kompach w firmie na Operze, IE6, IE7, IE8 oraz FX i wszędzie ruszył oprócz IE6 na 2 kompach, ale jak się dowiedziałem to owe przeglądarki coś "dorwało" i miały uszkodzone pliki przez co zachowywały się niestabilnie. A tłumacz to teraz klientowi, że winna jest jego przeglądarka. Już i tak co chwile się zastrzega, że jeśli coś nie działa to niech zmieni ją na nowocześniejszą. Ale jaki to ma efekt? Żaden, bo dział Pomoc na stronie odwiedzają nieliczni i połowa telefonów nawet by nie zadzwoniła gdyby zajrzeli tam. Klienci to leniwe istoty, które przy byle problemie dzwonią, choć w większości przypadków wina jest po ich stronie. Czasem potrafi bezczelność nawet wkurzyć. Przedwczoraj zbluzgano handlowca ponieważ na 2 dni przed końcem okresu promocyjnego przyszedł mail klientowi o konieczności wykupienia abonamentu. Kij z tym, że przez 60 dni korzystał za darmo z okresu promocyjnego. Nie podobało mu się, że taki mail mu przyszedl i twierdził, że zasypujemy go tym A w cronie jest wyraźnie, że takie maile przychodzą dwa: na 16 i 2 dni przed końcem okresu wygaśnięcia. Wychowanie klienta to chyba jednak podstawa. Niech nie liczy na złote góry. Niestety niektórzy zdają się tak wychowywać swych klientów i potem w całej branży są problemy.

Ale wracając do głównego wątku, czyli samego PHP i projektowania w nim optymalnego to trudno znaleźć złoty środek. Niestety pseudo-koderów jest masę. Rozumiem, że każdy zaczynał kiedyś, ale coraz częściej dochodzi do sytuacji, że zamiast pogłębiać oni swoja wiedzę w sposób samodzielny powielają oni spostrzeżone wzorce z błędami, nie zawsze rozumiejąc co robią. Jakiś czas temu był boom na AJAX, wcześniej to samo przechodził Flash. Gdy wchodziłem na stronę jakąś i widziałem wolno przesuwający się loader to zazwyczaj od razu zamykałem stronę, zanim się załadowała. Ciekawe co będzie takim "priorytetem" i dumą niedługo. Myślę, że niedługo każdy "szanujący się webmaster" na swojej stronie będzie musiał mieć coś w canvas i przejść na html5. Oczywiście nabijam się, ale tak z perspektywy czasu widzę tę branżę. Krótkie mody na określone technologie, po których następują kolejne. Nawet na forum widać, że obecnie w Polsce jest "na czasie" napisać grę przegladarkową co widać po wielu postach w serwisie. Ja sam zastanawiam się nad taką, ale u mnie jest to naturalne, bo planuje zmianę serwisu i użytkownicy na forum mnie o takie rozwiązanie pytali. A ja uważam to za ciekawe rozwinięcie systemu rang i avatarów. Zamiast standardowego obrazka i rangi - swoja postać, która wyrażałaby zaangażowanie usera w stronę i mocno z jego zachowaniem w portalu związana.

Zastanawia mnie jednak przede wszystkim ilość tych pseudo-koderów obecnie. Rozumiem, że Internet wciągnąć potrafi, ale skoro ktoś przyjmuje za punkt honoru sobie być adminem strony to czemu zamiast siąść z manualem w przeglądarce i jakąś "cegiełką" w ręku tycząca programowania oraz projektowania leci na forum mając ledwo mgliste pojęcie o html, niemal zerowe o php i chce pisać, nie potrafiąc nawet sformułować poprawnego pytania? Są przecież granice od których pytać o coś już jest wstyd.