Návrat od Rails k PHP

Jsem jeden z těch nadšených uživatelů Rails, ale určitě ne nekritický. Na začátku jsem měl TUNY pochybností, jestli jsem výměnou PHP za Rails udělal dobře. Přesně protože jsem nevěděl co se jak dělá, neznal jsem správné postupy atd. atd. atd. Asi tak 4. projekt se to zlomilo a od té doby nemám chuť se vracet zpět, protože moje produktivita oproti PHP šla rapidně nahoru.

Frameworky podporující určitý styl práce jsou taky skvělé při spolupráci více lidí na jednom projektu, docela účinně dokážou eliminovat vynalézavost lidí při psaní řešení, kterým nikdo jiný nebude rozumět.

nerikam ze by se clovek nemel ucit nove veci, ale.... Kdyz clovek dela v php uz nejaky patek a prejde na ruby, dela v tom nejaky projekt, bude ten projekt stejne kvalitni (po strance kodu, bezpecnosti, efektivity) nez kdyby ho psal v php (ktery uz tak trosku vice zna) nebo se na tom projektu uci ?

Ooo jak je ten posledni odstavec pravdivy :) Proto jsem - co se tyka PHP - presel od CakePHP ke CodeIgniteru. Porad toho dela dost, ale s diktatorskym Cakem se to neda srovnat (ja blbec jsem jim naletel na generovani CRUD views a controlleru). Ale kdyz muzu, sahnu po Djangu (coz bohuzel v praxi nejde tak casto, jak by si clovek predstavoval). Zatim v jeho pripade nemam pocity jako Derek (i kdyz pri uprave admin rozhrani jsem nejednou upel) a nevypada to, ze by me prepadly...

No a na veci, ktere nejsou databazove orientovane, ale spis textove, dokumentove, to nedam dopustit na XML a XSLT, obcas poslepovane pomoci PHP.

CodeIgniter a CakePHP jsou rozdilne vahove kategorie:

http://www.zenperfect.com/2007/07/15/faceoff-codeigniter-vs-cakephp/

Ohledne kodu, generovaneho pomoci CakePHP BakeShell: pokud Vam nevyhovuje, neni nic jednodussiho, nez implementovat vlastni [Controller|Mo­del|View]Task ci vlastni sadu sablon pro UI.

Posledni odstavec tohoto skveleho clanku je pro mne osobne prave jeden z duvodu, proc CakePHP jiz pres dva roky pouzivam - dukladna znalost CakePHP prinasi zjisteni, ze se jedna o velmi flexibilni nastroj, ktery 'pomaha a neprekazi'.

Nejde o to, ze by mi generovany kod z Bake nevyhovoval. Jde prave o to, ze jsem v touze zbavit se psani CRUDu sahl po Cake a pak zjistil, ze customizace toho generovaneho kodu je horsi nez to psat sam (videla jste nekdy ty sablony, ze kterych se ty views generuji? samozrejme, ze jsem je chtel prepsat, ale hodne rychle me to preslo).

Ve vami odkazovanem clanku jsou dost silene vety. Jako:

"If you have a small application for which procedural programming will work, CodeIgniter does its job. In short, CodeIgniter is better than no framework.

If you want to build a more complex application where a MVC design is necessary, then you will want to use CakePHP. "

Jedine vysvetleni pro me je, ze pisatel CodeIgniter ani nezkusil nebo nevi, co to je MVC a nebo taky nevi, co je to proceduralni programovani... Zajimalo by me, cim je podle nej Cake "vic MVC" a CI vhodny pro proceduralni programovani. Ze Cake pomaha a neprekazi... no nevim. Co mi koncepcne vadi, je implicitni vazba controlleru na model. V tom nevidim smysl. V CI je zcela na programatorovi jaky model bude chtit v danem controlleru pouzivat. Ne, ze by to v Cake tak neslo, ale uz to znamena vice zmen. Proc vazat M na C, kdyz tu je velka pravdepodobnost, ze budu chtit pouzit modelu vice? (MVC mluvi o vazbe 1:1 mezi V a C, nikoliv M) Druha vec jsou ty jejich uchylne inflections. Kdo by nahodou chtel v nazvech modelu pouzit neco jineho nez anglictinu, ma smulu, bude mit zkomoleniny nebo se zas musi v Cake hrabat. Ne, ze bych to chtel nejak moc delat, ale tohle je proste koncepcni chyba. No a nakonec je tu ta jejich parodie na ORM. Matersky objekt, ktery na dotaz vraci prachsprosta PHP pole? Ne, dekuji. (To je ta objektovost Cake?) CodeIgniter sice neumi vazby mezi tabulkami, ale s objektovosti je dale (procedural programming?) a kdyz jsou potreba vazby, neni problem zvolit third-party ORM (treba Doctrine). V CI je take fajn, ze staticke soubory jdou uplne mimo aplikacni adresar. Cake vam nadiktuje nazvy adresaru pro obrazky, JS a CSS a kdyz chcete jine, musite zas nastavovat.

Pripadne mi to presne naopak. Cake na male veci, kde je minimalni sance, ze pujdu mimo standard, CI na komplexni veci, kde potrebuju vice svobody (a mimochodem i znatelne lepsi vykon).

s doctrine je problem ze ide len na php5+, cakephp zvlada aj php4. ja viem ze php4 je stare a ze konci jeho podpora, ale vela hostingov ma este stale php4.

S PHP5 nemam problem. Zatim mam stesti na klienty, takze uz jsem PHP4 hodne dlouho nemusel pouzit. Me ted docela vyhovuje pouzivat DB vrstvu CodeIgniteru na operace smerem do db (update, insert, prip select s naslednou operaci zpet) a na cteni informaci pro ucel prezentace pouzit Query2XML a XSLT.

@Daniel Kvasnicka

Ano, videla jsem ty sablony :) a vzdycky pro me bude rychlejsi upravit vychozi sablonu a nechat si vygenerovat kod pro vice casti aplikace najednou.

Jaky model ci modely (vcetne zadneho) bude pouzivat Vas controller je jen na vas - nemyslim si ze zmena ve var $uses v controller kodu je az tak strasna prace ci velky zasah a uz vubec si nemyslim, ze by to bylo lze nazvat koncepcni vadou.

Pouzivat v nazvech trid/metod neco jineho nez anglictinu je imho ne moc chytre. A pokud po tom touzite, ono Vase 'hrabat se v cake' znamena upravu jednoho konfiguracniho souboru. A mimochodem - vetsina programatoru si ty 'uchylne inflections' chvali - tabulka 'people', controller 'PeopleController' a model 'Person' etc 'works just fine and out of the box'.

Objekty jako navratove hodnoty metod modelu jsou planovany pro milestone 2.0 - nicmene co se me tyce, vzhledem ke zpusobu jakym se s daty dale (predevsim ve views) pracuje, jsou imho pole plne dostacujici. Samozrejme - trvate-li na objektech jiz nyni, muzete pouzit Set::map().

Trvam na tom, ze rychlost vyvoje komplexni/rozsahle aplikace v CI a CakePHP je nesrovnatelna. A pri dnesnich cenach programatorske clovekohodiny je to zelezo proste levnejsi. Ja mam take rada rychle aplikace - coz znamena, ze tam kde vetsina nikoli preciznich programatoru s CakePHP aplikaci konci (po uspesnem testu funkcnosti oproti zadani), zacina faze optimalizace.

'Cake vam nadiktuje nazvy adresaru .... a kdyz chcete jine, musite zas nastavovat' - ano, to je dusledek jednoho z hlavnich hesel CakePHP core dev tymu: convention over configuration. A je to jedna z veci, kterou mame my pekari a cukrari na CakePHP moc radi :)

Nechci se nechat zatahnout do flamewar o tom, ktery framework je ten 'nej' - je-li nekdo spokojen s tim co/jak nabizi CI, budiz mu to prano. Ja bych si CI pro rozsahly projekt rozhodne nevybrala. Tim samozrejme netvrdim, ze to neni mozne, nebo ze je to chyba. Vzdy to bude o znalosti frameworku/ja­zyka/platformy a schopnostech programatora.

@ Jitka

Netouzim pouzivat cestinu v nazvech trid a metod, jen proste nemam rad, kdyz se nekdo snazi "myslet za me" :)

ORM pro milestone 2.0? Zajimave priority... ja si bez toho nedokazu kvalitni MVC framework moc predstavit. Jiste, ve views je to tem nekolika foreachum a forum celkem jedno, ty objekty jsou vetsinou stejne v poli. Jenze problem nastava ve chvili, kdy chcete z db vyzvednout data a na nich provadet nejake operace zpet do DB. Mit kazdy radek z tabulky jako instanci tridy s uzivatelsky definovanymi metodami, to je nedocenitelna vec. Zkuste nekdy ORM, kde to O ma nejaky vyznam a uvidite.

"Trvam na tom, ze rychlost vyvoje komplexni/rozsahle aplikace v CI a CakePHP je nesrovnatelna." -- tady jste ujela :) Ale kvuli cemu vlastne? Kvuli generovani CRUDu? To jste asi nezazila aplikaci, kde i customizace prototemplatu je malo, protoze naroky klienta na specificnost urcitych casti rozhrani jsou takove jake jsou :-) Jiny duvod, proc byste mluvila o rychlejsim vyvoji opravdu nevidim.

Convention over configuration... jiste, tahle filosofie ma sve misto, ale jako vse ostatni: dobry sluha ale spatny pan :) Nedokazu pochopit, v cem je tahle filosofie dobra pri urcovani toho, kde budu mit staticke soubory jako jsou obrazky... to je proste prehanka :) Proste a jednoduse, u Cake je moje zkusenost takova, ze to s touhle filosofii uz prehnali... jestli to vase zkusenost neni a jste s Cake produktivni, nemate co resit, proti gustu zadny disputat.

@Daniel
Opravdu se nechci hadat, takze:

ad 1) no comment
ad 2) model/behavior callbacks
ad 3) no comment
ad 4) no comment

Preji hezky den! :)

Skoda, ze ad 3) no comment :) Protoze ja bych rad slysel nejaky jiny objektivni argument pro vase odvazne tvrzeni. Ja totiz tvrdim, ze generovani CRUDu nemuze byt pro velke projekty v radu tydnu a mesicu argumentem pro "nesrovnatelnou rychlost vyvoje". Leda ze byste svuj vyrok opravila na "Z MEHO POHLEDU je rychlost vyvoje nesrovnatelna, protoze ME proste Cake vice vyhovuje" ;)

A k srovnavani behavior callbacks a ORM zas ja nemuzu rict vice nez no comment :)

@Daniel

Ehm ehm, to VY jste dosadil rovnitko mezi generovani kodu a moje tvrzeni o rychlosti vyvoje komplexni aplikace. Nezamenujte prosim prvni (bake tasks/templates) a paty (pocet clovekohodin nutny na vyvoj komplexni/rozsahle aplikace) odstavec v mem komentari, na ktery jste reagoval - nemaji spolu nic spolecneho.

Kod rozsahle aplikace se v case meni. Budete-li v tymu dlouhodobe pracovat na spolecnem kodu, jiste uvitate, bude-li pro vas kod nekoho jineho srozumitelny na prvni pohled - nikde neni psano, ze kod napsany vami osobne budete v budoucnu upravovat pouze vy osobne. A to je to, v cem se ocividne neshodneme - vy jste ze zasady proti konvencim, ja nektere povazuji za uzitecne - viz posledni odstavec prvniho komentare ('eliminace vynalezavosti'). Jako vlk samotar si delejte co chcete - tymova prace (ma-li byt efektivni) nejaka pravidla potrebuje.

Vite co je obvykly argument 'pro CI' pouzivany programatory, kteri prave objevili PHP? Ze jsou schopni produkce po par minutach cteni dokumentace a prikladu. Bohuzel, pouzivani frameworku jako je CakePHP chce nejaky cas venovany studiu a praxi, takze muj komentar k vasemu vykriku do tmy (jak je CakePHP strasne, protoze vas nalakalo na generovani CRUD, jehoz vystup neumite ovlivnit) je jen dalsi z mnoha, ktere (jako oficialni prispevovatel do CakePHP kodu a zamestnanec Cake Development Corporation) po webu trousim. NP, delam to rada ;) ale pod timto blog postem jsme jiz lehce off topic.

Na zaver: ja nesrovnavam model/behavior callbacks s enterprise ORM. Ja se vam jen snazim ukazat, ze reseni existuje, protoze vase argumenty proti CakePHP jsou liche - nastesti plynou pouze z absence detailni znalosti, nikoli z umyslu (coz pouze predpokladam z toho, ze jste v nasich luzich a hajich zrejme jeden z prvnich webdesigneru, ktery na svych strankach vyhradil pro CakePHP prvni misto ve vyctu pouzivanych frameworku).

Tim koncim, vase Jitka.

Jinymi slovy: don't panic! Hranice moznosti frameworku rozhodne nejsou to, na co jste narazil, Danieli :)

@ Jitka

Opravdu nevim, na co narazite odstavcem o spolecnem kodu, jeho zmenach v case (jaka novinka :D) a ctenim kodu cizimi osobami...to je nejak k tematu? Nebo jste tim snad chtela rici, ze pri pouziti CI neni mozne tohoto dosahnou? Konvence, draha Jitko, jsou produktem skupiny lidi, kteri si je dohodnou a dodrzuji. Ze vam vyhovuje, ze vam ty konvence nebo jejich cast stanovi nekdo jiny, to je vec druha. Ja kdyz pracuji ve skupine lidi (ano, opravdu uz se mi i takova vec stala...), stanovime si konvence sami a pak je pouzivame -- k diskusi o frameworku je to naprosto irelevantni, placate mistem v DB, na ktere jede blog.root.cz :)

Prave objevili PHP :) To nebyla narazka na me, ze? :) Ja jsem studoval Cake docela dost (nehlede na to, ze to ani nahodou nebyl muj entry point pro PHP, ten se odehral nekolik let predtim), ostatne napsal jsem v nem nejednu docela velkou aplikaci. Nenadavam na nej, protoze jsem si o nem neco precetl, ale proto, ze jsem s nim zazil neco, co se mi nelibilo.

Nevim, jaka detailni znalost o behavior callbacks by mi mela chybet, napouzival jsem se jich v Cake az az, jenze na rozdil od vas jsem take mel to stesti, ze jsem psal aplikace s minimalne dvema opravdu objektovymi ORM (nemusite pouzivat hned slovo enterprise, to zavani monoliticnosti Javy, slusnych ORM je dost a jsou to relativne lightweight knihovny), ktere jsou intuitivitou daleko pred Cakem. "Reseni existuje" je malo, me zajima system, ktery se co nejvice priblizuje tomu, jak clovek premysli o problemove domene, realnemu svetu. Od ceho si myslite, ze vzniklo OOP. Aby pak nekdo tvoril neco jako je Model v Cake?

Takze secteno a podtrzeno: zatim jsem se od vas dockal narazek na to, jak jste dobra, narazek na me, jak ja nejsem, ale nejaky rozumny (a hlavne OBJEKTIVNI) dukaz o tom, ze "rychlost vyvoje komplexni/rozsahle aplikace v CI a CakePHP je nesrovnatelna" veskery zadny. Tak treba priste :)

Na zaver bych se rad omluvil p. Cimprichovi za to, ze mu tak plenime blog ;)

@Daniel

Hmm, koukam ze CakePHP uz na strankach neni vas 'prvni' framework. No - alespon, ze vas nejrozsahlejsi projekt z portfolia je postaven na nem. Takze u me mate bod :)

ad 1) Preji vam mnoho uspechu pri domlouvani konvenci - pokazde znovu a znovu, s novymi lidmi a jejich navyky, nad kazdym novym projektem... A skutecne od srdce vam preji, aby jste to byl pokazde POUZE VY, kdo bude muset po letech upravovat VAS kod nebo kod tymu, jehoz domluvene konvence jiste budete mit i po letech zazite.

ad 2) Ne, poznamka o 'programatorech kteri prave objevili PHP' byla jen pro vasi predstavu, co maji PHP zacatecnici na CI nejradeji - vite, srovnavani kladu a zaporu ostatnich frameworku pro rychly vyvoj webovych aplikaci se v cake dev teamu venuje znacna pozornost - odtud 'nejvetsi plus frameworku CI for everyone'. K memu prvnimu komentari me vlastne primelo vase legracni oduvodneni vykriku 'ooo jak je posledni odstavec pravdivy'.

ad 3) Nic o vas nevim - krome obsahu vasich komentaru na teto strance, a toho, co pisete na vasich strankach. Neznam nikoho jmenem Daniel Kvasnicka - takze predpokladam, ze Daniel Kvasnicka bude jen stezi znat me. Pouzivate-li obraty jako 'zkuste nekdy ... a uvidite', 'to jste asi nezazila' ci 'na rozdil od vas', zajimalo by me, z jakych zdroju cerpate informace. Oproti vam jsem totiz ve znacne nevyhode - ja nemohu posoudit jediny radek kodu, ktery jste vy napsal, zatimco ja jsem zapichla ceskou vlajecku na nekolika mistech kodu CakePHP.

ad 4) Mate-li pocit ze vas nejak shazuji, omlouvam se - mam takovou tendenci u lidi, kteri postradaji schopnost zustat vecni a nad veci. Mozna jsem se jen nechala svest tim, ze primarne inzerujete design - programovani je v nabidce vasich sluzeb az na druhem miste. Takze jste mnohem mnohem lepsi - ja jsem se za tech temer 25 let (co jsem se dotkla klavesnice poprve) o design ani nepokusila. Klobouk dolu, Kvasnicko juniore. Prectete si prosim komentare znovu, zacnete vasim prvnim, mym prvnim, a pokracujte dal. PEVNE DOUFAM, ze se vam podari zachytit to, o co mi slo - reagovat na nepravdiva tvrzeni, popripade ukazat zpusob reseni tam, kde v CakePHP tapete, nebo se proste jen mylite.

ad 5) K tomu bych se rada pripojila ;)

ad 1) Konvence na ruznych projektech nejsou vzdy disjunktni mnoziny. Mnoho konvenci se dari domlouvat stejne a radsi budu mit u kazdeho projektu nektere konvence jine nez nechat tym brzdit tim, ze se bude smirovat s necim, co jim nevyhovuje. Mimochodem, krome konvenci take existuje dokumentace, ktera pokud je dobre zpracovana s ohledem na to, ze do toho budou koukat i jini, nevidim duvod, proc by odlisne konvence mely byt takovym strasakem, jakeho z nich delate...

ad 2) Kdyz se tolik venujete srovnavani frameworku, tak jak sem muzete dat odkaz na clanek, ktery obsahuje tak stupidni vety? CI pro proceduralni programovani, Cake "vic MVC"... "MVC design in CodeIgniter is just not developed." a vety zatim... on si snad mysli, ze vyvinutost MVC designu zavisi na tom, kolik toho umi M vrstva!! Slysel ten pan nekdy o tom, ze MVC je pattern, ktery vznikl davno pred tim, nez vubec nejake web db aplikace byly a nemel v pocatku s webem absolutne nic spolecneho? Vzdyt ten clovek vypada, ze opravdu nevi, o cem mluvi. Vypada to, jako kdyby si prave nekde neco precetl a aby svetu ukazal, ze uz se strasne vyzna v MVC frameworcich (to prece kazdy v dobe Web 2.0 musi, jinak je outsider), tak napise clanek...

ad 3) napodobne, take znam jen vase komenare a jestli jsem se nechal unest a vas se to dotklo, tak se omlouvam. Nejspise to bylo tim, jak vytrvale delate z Cake modelu rovnocennou alternativu k ORM a tim "skvelym" clankem... Nepochybuju o tom, ze jste kvalitni programator (no irony).

ad 4) To jste se asi nechala. Design tam sice mam primarne, ale procentualne se venuji mnohem vice programovani a posledni dobou me to i vice bavi. Vyhovet totiz nekdy necimu "estetickemu citeni" je dost unavne... S kodem to je jednodussi.
Zpusob reseni jste ukazala, ale ja ho povazuju za nedostatecny.

Jen pro upresneni: 'poslednim odstavcem tohoto skveleho clanku' jsem myslela posledni odstavec tohoto skveleho blogpostu, samozrejme - coz by nemel by problem poznat podle kontextu.

@Petr Cimprich

diky za link! :)

'Rails was an amazing teacher.'

Pod to bych se podepsala. Vylet smerem php -> ruby -> rails -> php se mi take mimoradne libil.