Vlákno názorů k článku Ruby on Rails: Úvod od anonym - Rails jsem chvíli studoval a zkoušel, ale vrátil...
-
anonymníRails jsem chvíli studoval a zkoušel, ale vrátil jsem se zpět k PHP (na malé věci) a Javě (na velké věci).
Přijde mi to jako framework pro "programátory nové doby". Dřív jsme se nikdy nepozastavovali nad tím, že si musíme většinu kódu napsat sami. Taky se časem dobereme k výsledku a má to tu výhodu, že po každém projektu programátor znalostně naroste, má plnou kontrolu nad celým projektem, kterému zcela rozumí a nebyl problém upravit úplně cokoliv.
Dnešní mladí programátoři mají zcela jiný styl práce. Po obdržení zadání nejdřív spustí google, natahají neskutečné množství knihoven, které "by se mohly hodit" a podobných hotových aplikací. Potom bezmyšlenkovitě a roboticky jen lepí kus toho a kus onoho dohromady, aniž by všemu zcela rozuměli ("dyť to funguje"). Vůbec nad ničím nepřemýšlejí a zdaleka nemají nad projektem plnou kontrolu. Když něco nefunguje, tak nemůžou najít chybu ve změti cizích a vlastních bugů a jsou zcela ztraceni. Ale nevadí jim to.
Podobně se pracuje i v Rails. Něco vygeneruju, sem šáhnu, tam šáhnu a je to hotové. Když chci něco jinak, tak to přece nebudu předělávat, radši to nechám jak to je, aby se to náhodou nerozbilo.
Tenhle způsob práce je pro mě zcela nepřijatelný. A dovolím si tvrdit, že dokážu dojít ke stejnému cíli v podobném čase. V praxi se totiž zadání často tak liší, že se na ně snažit napasovat "univerzální řešení" není uskutečnitelné. A na společné věci si každý normální programátor napíše v krátkém čase své jednoduché knihovny, které jsou jeho stylu práce šité na míru.
Nemusíte se mnou samozřejmě souhlasit, moje názory se mohou lišit i jinde. Například o Smarty si myslím, že to je strašný pokus. Tvrzení, že v šablonách mohou být ify a whily, je zcela nesmyslné. Pokud totiž kód obsahuje jakoukoliv logiku, při každé úpravě šablony bude muset být zapojen i programátor (kromě kodéra) a útrpně pomáhat lepit celek. -
anonymníMáte nějaké zkušenosti s frameworkem Expresso od JCorporate? JBoss je často kanon na vrabce, tak hledám vhodný framework v Javě. Jiné doporučení? Díky
http://www.jcorporate.com/ -
ortiga (neregistrovaný)Mozna patrim mezi "programatory nove doby", ale myslim, ze napr Ruby on Rails snadno cloveka odvede presne od zazitych a casto chybnych vlastnich reseni a posune ho "nasilim" k lepsimu/praktickemu reseni. Dokumentace k RoR obsahuje i kod metod, takze pro zvidaveho programatora neni problem si zjistit, co pouziva.
Nikdy jsem si cizi reseni nestahoval z internetu, naopak jsem premyslel, jak bych si mohl ulehcit praci v PHP s SQL napsanim vlastniho "frameworku", ale po objeveni RoR jsem tuto potrebu ztratil, vymyslel bych znovu neco, co jiz existuje v mnohem lepsi podobe, nez jake bych dosahl sam. Nezanedbatelnou vyhodou RoR je kvalita kodu framewoku, myslim, ze srovnani s postahovanyma knihovnama z netu to skutecne nesnese.
Neposledni argument pro RoR je, ze se stejnak v praxi pouziva ruzne firemni framworky postavene nejlepe na jinych framworcich a Java je teto zbesilosti zrovna nejlepsim prikladem....btw: jak mi bylo receno, kdyz jsem ze uchazel o praci u jedne z vetsich ceskych firem, "Skoleni naseho firemniho frameworku je velmi dulezite pro zapracovani, trva 6 celych dni a bez absolvovani byt jedineho dne se vam muze stat, ze nic nepochopite....." - znamena to snad, ze k tomu ani nemaji dokumentaci? ;D
Nakonec se bavime jen o urovni abstrakce. Kdyz to prezenu, tak se muzem rovnou vratit k assembleru, vzdyt vyssi jazyky nam jen brani skutecnemu pochopeni programovani.... Mirnejsi priklad je pouziti napr C++ bez stdlibrary - stromy, zasobniky by mel take kazdy umet naprogramovat sam...a co kdyz to uz umi, musi porad pouzivat svoji ne uplne vylazenou implementaci? -
anonymníok. respektuju tvůj názor. spor je asi jenom v tom, jaká úroveň abstrakce při vývoji web aplikací ještě pomáhá a jaká už otravuje.
ale prosil bych - je nutné šířit slovo "vylazenou"? Co to má znamenat? Je to snad nějaká odvozenina od "vymazlenou"? Slovo "vyladěnou" zní snad málo spisovně a odborně? -
ortiga (neregistrovaný)>>ok. respektuju tvůj názor. spor je asi jenom v tom, jaká úroveň abstrakce při vývoji web aplikací ještě pomáhá a jaká už >>otravuje.
Ano i ja respektuju jine nazory, snad nevyplynul z me reakce opak.... Pomaha x otravuje - napr na vytvoreni administrace je to uzasny nastroj, pro aplikaci s velkym poctem pristupu nevim. Jde jen o konkretni souvislosti, ale na tom se verim shodujeme.
Zajimave jak casto verejna diskusni fora, nehlede na zamereni, zabredavaji do reseni spisovne cestiny ;]
Do ted jsem "ladění - lazení" a "sedění - sezení" povazoval za obdobny priklad dublet....po kratkem hledani clanku na toto tema jsem pochopil, na co narazite. Ano nevedel jsem to, cely zivot mam napr kytaru "nalazenou" a ne "naladenou", protoze mi to tak neleze z huby....Jiz se tesim na nova pravidla pravopisu, ktera dozajista posunou spisovnnou cestinu bliz skutecnosti stejne tak, jako to udelala pred par lety. -
deseado (neregistrovaný)" ... cely zivot mam napr kytaru "nalazenou" a ne "naladenou", protoze mi to tak neleze z huby..."
No je treba vice cist literaturu a vubec se tak nejak sebevzdelavat vseobecne a ne jen pouze v Ruby :) Pro cestinu je treba cit uplne stejne jako pro programovani. Chybna cestina obvykle signalizuje nepozornost a sklon k rychlym resenim bez dohlednuti jejich dosahu dale, nez za uzaviraci zavorku kodu :) -
Tak trochu flamu:
Dřív jsme se nikdy nepozastavovali nad tím, že si musíme většinu kódu napsat sami.
Jistě, ani já jsem se v dávných dobách nepozastavoval nad tím, že si pro velké pole musím alokovat diskovou stopu a vyřešit si "swapování" mezi diskem a 64 KB RAM. Možná jsem líný programátor nové doby (nikoliv už mladý), ale to, že se mi o swapování nyní stará OS (a v 99.9 % naprosto uspokojivě), mi zcela vyhovuje a netoužím mít nad tím plnou kontrolu. BTW, jak můžete dělat v Javě, když tam nemůžete nijak zvlášť moc ovlivnit správu paměti (GC)? Nebylo by lepší staré dobré C, kde máte nad alokací a uvolňováním paměti plnou kontrolu (malloc a free)?
A na společné věci si každý normální programátor napíše v krátkém čase své jednoduché knihovny, které jsou jeho stylu práce šité na míru.
Většina webových (a asi i mnoho newebových) aplikací pracujících s relačními databázemi s výhodou užije ORM. Nemyslím, si, že by bylo rozumné a efektivní, aby si to psal každý sám pro všechny možné databáze, přesto že by měl pak nad tím plnou kontrolu.
Tvrzení, že v šablonách mohou být ify a whily, je zcela nesmyslné.
Doporučuji výborný teoretický článek http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf o tom, co je a není nutné v template enginech. Implementace těchto myšlenek jako "minimální" rozumné template engine je pak StringTemplate a stejně je tam if a v podstatě i cyklus (tedy jen foreach, nikoliv while)
-
Možná mi něco uniká (a taky už je to nějakou dobu, co jsem se tím zabýval podrobněji), ale StringTemplate v podstatě splňuje první dva požadavky. Svou konkrétní šablonu si přece můžete vytvořit jako pěkné formátované validní XHTML (a ty dolary přeci validitě nebrání). Nicméně při tomto přístupu nemůžete šablony "includovat" (protože do kompletního validního XHTML nelze vložit jiné kompletní XHTML), což nejspíše povede k tomu, že pokud třeba více stránkách chcete mít stejná záhlaví a zápatí, tak ten XHTML kód musíte v každé šabloně opakovat. A šablony by měly sloužit právě k tomu, abychom se opakovat nemuseli.
Nechápu ani, jak by v šablonách mohla fungovat vzorová data místo nějakého uvedení názvu proměnné, jejíž hodnota se má dosadit. Pokud například je v textu "1.12.2005", jak pak poznáte, že to není text, ale vzorová data, kam se má dosadit třeba aktuální datum a jak odlišíte, že při jiném výskytu "1.12.2005" se má dosadit třeba datum poslední aktualizace stránky? Navíc to ani není přehledné. Napsat v těchto případech třeba $today$ a $page.last_modified_on$ mi přijde logičtější. -
V tom je právě ta potíž. Pokud to má být skutečně validní XHTML, tak nelze "vymyslet" nový atribut pro tento účel (resp. ne ve jmenném prostoru XHTML). Šlo by jedině "zneužít" existující atribut (ale to mi přijde dost dost drsné, protože ty již mají definovanou sémantiku - může dojít je kolizi) nebo deklarovat nový jmenný prostor a použít atributy nebo prvky z tohoto nového prostoru (ale to je pak zase velmi jednoúčelová šablona, která by šla použít jen na značkovací jazyky založené na XML - tedy ke generování XHTML ano, ale pro HTML ne - a navíc mi pak přijde zbytečně složité parsování).
Stejně nevidím (pro sebe) žádnou výhodu v tom, že by moje šablona měla být hezké validní XHTML. Snad kromě toho, že bych si ji mohl přímo prohlížet a "ladit" v prohlížeči. To ale v dnešní době, kdy se spíše značkuje jen "struktura" dokumentu a formátuje se přes CSS, mi nepřijde tak významné. -
anonymníSpousta frameworku zvelicuje vyhodu editace sablony, ale v praxi se nesetkavam, ze bych do sablony musel nejak vyrazne hrabat par mesicu po spusteni site. A jestli ano, pak zmenu dela vetsinou jiny html koder (pripadne tentyz, ktery uz sablonu samozrejme zapomnel). Nez vychazet z existujici sablony a pak dva dny resit, proc je to rozhozene v IE, je lepsi udelat uplne novou sablonu.
XHTML validita se beztak nejlepe zjistuje, ze do validatoru zadate url. -
ondrej (neregistrovaný)Aha, takze se nemam spolehat na knihovny ktere prede mnou pouzila a tim i otestovala spousta lidi, ale mam si je napsat sam, coz mi zabere mnohem vic casu a vysledek bude mnohem zabugovanejsi ? Ja bych vlastne touto cestou rad sel, clovek si urcite dobre a zajimave "zaprogramuje" a programatorsky vyroste, ovsem co mi na to asi rekne muj zamestnavatel a zakaznici ... ?
-
disposable (neregistrovaný)toto uplne vyjadruje moj nazor. z celeho ruby on rails mam pocit, ze je to konzolova obdoba WYSIWYG editorov. neviem posudit ci je to vec dobra, alebo nie, to zalezi od cistoty underlying kodu, ale vela mudrosti jeho uzivatelia nepoberu.
este k tomu
"Vůbec nad ničím nepřemýšlejí a zdaleka nemají nad projektem plnou kontrolu."
ja pri kodovani JAVY tiez velmi nerozmyslam. jednoducho rozdelim vsetko pred zacatim kodovania na male kroky a kod ide sam. zeby TAO?
www.canonical.org/~kragen/tao-of-programming.html -
Normalne bych s vami souhlasil - jenze tady se bavime o webovskych aplikacich. U webovskych aplikaci tento styl prace skutecne nevadi (mozna s vyjimkou skutecne velkych veci, ale pak je nejlepsi oddelit webovou a slozitou cast) a proto si myslim, ze tu maji systemy typu ruby on rails skvelou prilezitost. Ono ani to PHP neni dobre pro velke projekty ...
(Naopak java je diky overheadu naprosto nepouzitelna na projekty male - nebo na "klasicky" web, ve kterem se pousti program zvlast na kazde zobrazeni stranky).
Jinak, co se tyce jednoduchych knihoven, neni dulezite je napsat, ale pochopit. Osobne si taky myslim, ze napsat je je nejjednodussi metoda jak je pochopit, ale nekteri asi nebudou souhlasit.
