HH,
megpróbálom összefoglalni a programozási stílusokat. a chart-os példánál maradva:

chart?par1=val1&par2=val2...
chart(par1 => val1, par2 => val2);
chart = new chart(val1, val2);
create_chart(val1, val2);

mindnek van előnye, hátránya.
néhányat felsorolok közülük.

az elsőt a parancssorból is kiadhatod, ellentétben a többivel. viszont paraméterként itt csak egyszerű értékeket adhatsz át ellentétben a többivel.

a második esetben a paraméterek számát tetszőlegesen tudod növelni, csökkenteni, mert előzetesen deklarálva vannak az alapértelmezés szerinti értékek. viszont cím szerinti paraméterátadás itt nem jöhet szóba, az ilyen eljárás képtelen hatni a környezetére.

most van aki szerint ez a tuti, mert akkor nincs mellékhatás, mások szerint meg a programozás lényege, h ilyen mellékhatásokat okozzunk.

a harmadiknál az eljárás tárgyát utólag manipulálni tudod ellentétben a többivel. viszont a létrejött objektumot többnyire el kell menteni, mert a program az utólagos manipulációra épül.

valójában mindegyik stílust, vagy ha úgy tetszik iskolát követve célt lehet érni, ettől függetlenül a legtöbb programozó esküszik egyik, vagy másik technikára.

hosszú ideig ez előny volt. amíg kevés volt a programozó, mindenki megtehette, h oda ment dolgozni, ahová akart, egy ismert, begyakortolt stílust követhetett.

ma a programozók össze-vissza keverednek, és már nemcsak cégen és projekteken, de egyetlen programon, sőt egyetlen blokkon belül is keverednek ezek a stílusok. az összes létező technológia lehetőséget ad ugyanis az átjárásra, különben elszigetelődnének. így egyik programozó átírja a másik kódját a saját hite szerint. na most irgalmatlan káoszt eredményez a gyakorlatban.

de ettől még mindegyik eszközrendszerrel célt lehet érni, körülbelül azonos idő alatt.

Én kiváncsi vagyk mi lesz :)

Valóban nagy volt a hype a Rails körül. De akkor is, hogyha nem váltotta ki igazából a korábban használt keretrendszereket és csak a siteok pár százaléka készül RoR alapon, el kell ismerni, hogy nagy hatással volt más rendszerek fejlődésére és ezt azok fejlesztői sokszor el is ismerik.

Minden hibájával együtt jót tett a világnak, megmutatta, hogy másképp, szebben, könnyebben is lehet.

koszi kutacs_ a programozasi alapismereteket :) kerdes az lenne, hogy mi koze ennek a RoR-hoz? komolyan kerdes, mindenfele ironia nelkul, ugyanissemmi fogalmam sincs az RoR-rol. parametert viszont at tudok adni nehany fele keppen :P

A Ruby on Rails szuper. Egyetlen gond van vele, az üzemeltetése hoszting környezetben. Egyetlen hoszting céget ismertem itthon, amelyik bevállalt RoR üzemeltetést, a sajátomat, aztán végül én is becsuktam a boltot inkább (ezzel együtt lehet jól és hatékonyan üzemeltetni, de célszerű egy saját szerver a RoR-os cuccoknak). Talán azóta változott a helyzet. A Perl és Python egyik baja is ez különben, és ezért is szárnyal a PHP.

szerintem azt kell látni, h ezek a stílusbeli keveredésekből fakadnak a problémák.

nyilván fel lehet tenni a kérdést, h miért nem jelenik a gchart a táblázatkezelőben, de fel lehet tenni is, h miért nem jelennek meg az új diagramok az analyticsban, illetve az ottani diagramok eddig miért is nem voltak eddig közvetlenül elérhetőek.

erre az a válasz, h a google sem követ egy egységes stílust. és így nehéz összekapcsolni a fejlesztéseket.

ha mindenhol mondjuk url technikát követték volna, most egyszerű dolguk lenne. ebben a felfogásban minden url egy frame-t azonosít, egy belső url egy belső frame-t.

a gdocsban a munkalap valójában egy frame, a diagram készítéshez egyszerűen meg kell adnod a munkalap néhány jellemzőjét, annak a részeire meg egy konvencióval hivatkozhatsz, például a1:a10 jelöli az a oszlop első 10 sorát. és ezt beilleszthetnéd egy url-be, illetve egy url-en keresztük bármilyen frame-be.

az analyticsban most használhatnál egy csomó új diagramot, hiszen a látogatottsági statisztika is egy frame, és akár annak egy része, vagy az egész megjelenhetne a gdocs-ban. minden szép és jó volna. a statisztikát read only módban a gdocs-ban meg lehetne tekintheteni, annyi kellene, h minden google url-hez tartozzon valamilyen authetintikáció. lehet, h csak annyi, h rákérdezünk a gépre, ki vagy, de lehet, h rákérdezünk az emberre is. lehet, h csak olvasást engedünk meg, lehet, h írást is. ez előre definiálva van.

de ezeket nem vitték végig ilyen következetesen. az authentikáció úgy ahogy működik, de nem ragaszkodtak az url technikához, vagy bármi máshoz. így ugyanúgy szétestek a fejlesztések, mint a legtöbb helyen, illetve hiába történtek meg a felvásárlások, a szolgáltatásokat nehezen tudják integrálni.

és ennek oka, h a programozók többsége bigott módon hisz valamiben, a másik részük pedig pont az ellenkezőjében. például vannak olyanok, akik szerint belső frame-eket csak java scriptből szabad nyitni és szerverrel csak xml segítségével kell kommunikálni. ők az ajax játékosok.

az url esetén érték alapú a kommunikáció. ebben az esetben nem lehet bonyolult struktúrát cserélni, viszont maga az adatcsere sokkal egyszerűbb. nyilván mindkettő mellett szólnak érvek és ellenérvek, de ha a csapatot előzetesen egy emberi erőforrás szakember válogatta össze gyakorlatilag véletlenszerűen, és a projekt vezető ezeket a technikákat nem ismeri, akkor nagyon nehéz rendet csinálni, mert valójában lehetne így is, meg úgy is, de azt nem lehet, h hol így, hol úgy.

és egyelőre még nincs olyan eszköz, vagy nyelv, ami ezeket a technikákat egyesíteni vagy egységesíteni tudná. mindig jön valami, amire sokan felesküdnek, de aztán mindig kiderül, h valami nincs kellő módon támogatva, és egy csapat meg pont abban hisz. és akkor összejönnek, és kenterbe verik a világot. így látom ezt. persze lehet, h nincs igazam.

bl,
igazából arra akartam válaszolni, h mi az a speciális terület, ahol a ruby-t lehet használni. szerintem nem lehet ilyen területeket kijelölni. szerintem az összes ma divatos eszközzel célt lehet érni, nagyjából hasonló idő alatt.

Az, hogy nem sok minden tortent az elmult ket evben azert eros bagatelizalasa a dolgoknak. Annyira tortent, hogy egesz sok hasonlo elvekre epulo rendszer szuletett. Ott van ugye a Pythonban a Django (bar az inkabb egyszerre jott ki a Railsszel, es nem majmolja, egy par dolgot maskepp csinalnak, megis eleg hasonlo), az emlegetett PHP-hez keszult a Cake PHP, a javas keretrendszerekre is hatott (Grails, meg meg van valami hasonlo).

Az, hogy sok programozo dolgozik tovabbra is PHPban egyaltalan nem jelent semmit. Ket ev nem tul sok ido ahhoz, hogy eleg sokan valtsanak. Ezen kivul van egy csomo programozonak latszo ember, aki egyaltalan nem az (sorry). Ismer egy programnyelvet, abban ossze tud rakni valamit ugy ahogy. Igen sok esetben ez a PHP, regebben meg a perl volt. Azert, mert a kozhangulat ezeket nevezte ki 'webes' programozasi nyelvnek, ezert a hozza nem erto, es energiat befektetni sem akaro kezdok ezt valasztjak, es ott le is ragadnak. Az ilyen arcokat arrol is fel lehet ismerni, hogy olyan celokra is a PHPt probaljak hasznalni, amire az nem valo (lasd valamelyik iwiw kisegito scriptet, amihez meg kellett volna adni a jelszavad, vagy a masikat, amihez PHP scriptet kellett volna telepiteni egy serverre).

Rails hosting ugyben azert kulfoldon ugy hallottam jobb a helyzet, es vegso esetben siman berelhetsz egy VPS-t. Az ugy is jobb megoldas, de persze Mo-on azt sem lehet megfizetni. Meg jo, hogy ugyanaz az internet van kulfoldonis, mint itthon ;-))

ha valaki nekiáll php-ben egyszerű értékekkel és közönséges függvényekkel operálni, és minden részproblémára felépít magának egy modult, amit aztán folyamatosan bővít, illetve szűkít, akkor az egyszerű problémák esetén könnyedén célt érhet, és a bonyolultabbakkal találkozva is elég messzire juthat.

az persze igaz, h a hardcore programozók egy ilyen softcore gyereket rendszerint megesznek reggelire. mert ő a struktúrákat folyton szétszedi. azaz amit az egyik felépített, azt a másik le akarja bontani. szerintem a gyakorlati problémák ebből adódnak.

szerintem el kell fogadni, h van egy moduláris, funkcionális, minimalista programozási stílus, ami kétségtelen, h nem egy barokkos építkezési mód, de egy létező iskola, és ha valaki ezt tudja, akkor már tud valamit.

A ROR adta nekünk a Zend Frameworköt.

Két dologban hozott a Rails újdonságot.

Az egyiket mint (MVC) keretrendszer hozta. Természetesen nem a Rails az első webes keretrendszer, de az talán állítható, hogy a webfejlesztés területén a keretrendszer-szemlélet elterjedésében, azaz abban, hogy az addigi két véglet, a CMS-, ill. "megcsinálom magam"-szemlélet helyett (mindkettő járhatatlan: az utóbbiban a programozónak újra fel kell találnia a kereket, az előbbiben pedig programozás helyett tkp. testrehackelés a feladata, persze most túlzok) a keretrendszer a fejlesztői közösség tudatában elsőrangú helyre került, a Rails nagy szerepet játszott, sőt. Nem véletlen, hogy ezidőtájt kerültek előtérbe a php-közösségben is a részben a Rails nyomán készült (részben nem), s vele egy kaliberű framework-ök. (Ez még a weblaboros álláshirdetésekből is kiolvasható.)

A másik újdonság a Rails-szel kapcsolatban a nyelv, amit használ; pontosabban nem a Ruby maga az, ami új (bár a Rails előtt elhanyagolható volt az ismertsége), hanem a Ruby, tágabb értelemben pedig az általános célzatú szkriptnyelvek mint webes szerveroldali nyelvek. A Ruby, ha lehet ilyet mondani, az egyik "legtipikusabb" szkriptnyelv: dinamikus, gyengén típusos, tömör szintaxis stb., s nem utolsósorban talán minden más nyelvnél jobban épít a metaprogramozásra. Ilyen szkriptnyelvet eddig webfejlesztésben nem használtak. A PHP vele szemben reménytelenül konzervatív nyelv, merev, szinte archaikus szintaxissal. (Abban, hogy a PHP ennyire elterjedt, főleg marketingokok játszanak szerepet.) Az tehát, hogy egy általános célzatú szkriptnyelv is jól, sőt jobban használható webfejlesztésre, mint az elvileg erre a célra specializált PHP, szintén nem kis részben a Railsnek köszönhető. Az sem véletlen ugye, hogy a Pythont is hirtelen ekkortájt fedezték fel mint webfejlesztő nyelvet, pedig a Pythonra nem mondható, hogy azelőtt ismeretlen lett volna.

atleta:

1. alljon meg a menet, amiket felsoroltal, azok a railsen KIVUL eso fejlesztesek. meg jo h a railsen kivul nem allt meg az elet :) a post viszont arra utalt, h a _rails-szel_ nem sok egetrengeto dolog tortent.

persze hatott mas fejlesztesekre, de a pld. cake a rails nelkul is kijott volna, stb.

2. "Az, hogy sok programozo dolgozik tovabbra is PHPban egyaltalan nem jelent semmit." - dehogynem.. pld. azt, hha en project manager vagyok, es platformot kell valasztanom, akkor a php-nek megvan az az elonye, h konnyebb/olcsobb embert talalni.

az, h sok a felamator/amator, egy projektmanagernek meg jo is, mert lejjebb viszi az arakat.

tl;dr: php-s emberekhez kepest keves rubys van es dragak, ami hatrany.

javítás: "Az tehát, hogy egy általános célzatú" -> "Annak a felismerése tehát, hogy egy általános célzatú"

Rails:

www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

REST:
www.xfront.com/REST-Web-Services.html

fraki,
szerintem ezek miatt nem lehet azt mondani, h a ruby "jobban használható", mint a php. inkább csak azt, a "ruby nekem jobban tetszik, mert kifinomultabb az eszközrendszert kínál, mint a php".

a php sikere éppen abban rejlik, h a leghülyébb is tud benne programozni. például ha véletleszerűen összeállítanak egy csapatot, és kezdeni kell valamit, akkor a php lehet közös nevező.

azt gondolom, h a használatban levő nyelvek nagyjából egyenrangúak. a banki rendszerek jelentős része ma is cobolban fut, úgy, hogy azokban dinamikus tárkezelés sincsen. de ez nem azt jelenti, h a cobol banki rendszerek írására való. a cobolnak meg van a maga logikája. egyszerű kimenent-bemenet kapcsolatokra kell építeni. és ezzel bármit meg tudsz csináln. más kérdés, hülyeség ma nekiállni cobolban programozni, mert kevés a támogatottsága, de maga a nyelv éppúgy univerzális, mint a ruby.

ráadásul vannak még hülyébb nyelvek. például forth. ha valaki a fejedhez rak egy pisztolyt, és muszáj forthban programozni, akkor előbb összefosod magad, de nem a pisztoly miatt, hanem a forth idiótizmusa miatt, egy idő után viszont már csak forthban akarsz programozni. így van ez az összes nyelvvel.

Flamebe elvbol nem csatlakozom be. Azt viszont el tudom mondani, hogy en foleg miert RoR-t hasznalok. Mert ebben tudom leghatekonyabban kifejezni magam. Sokat PHP-ztam, probaltam nagy rendszert PHP-ben nullarol, PHP-ben keretrendszerekkel, Drupal hackelessel, de szamomra mindegyiknel szebb, jobb idegkimelobb megoldas volt a RoR.

kutacs: cobol, forth stb.: weben használt nyelvekről van szó. Ezek nem azok.

"a php sikere éppen abban rejlik, h a leghülyébb is tud benne programozni."

Nem. Egész más okai vannak a sikerének. Másrészt ebben a kérdésben indifferens az összes programozási nyelv.

off: kezdem ruhelleni a coolspace-t.

"Nem. Egész más okai vannak a sikerének. Másrészt ebben a kérdésben indifferens az összes programozási nyelv."

Szerintem ez igenis fontos szempont. Egy nyelv lehet bármennyire is jó és erős, ha nincs tapasztalt fejlesztő, nem fog befutni. És minél körülményesebb megtanulni, annál kisebb az esélye, hogy sikeres lesz.

Watchman: a hülyék mindenben programoznak, és semmiben sem tudnak. A hülye webfejlesztő azért php-zik, mert azt tolják elé. Ez támogatottság és marketing kérdése.

Az internet explorer sem jobb attól, hogy a hülye azt használja.

ha egy csapat különböző felkészültségű emberekből áll, akkor a php a legjobb választás. gyakorlatilag bárki tud benne programozni.

szerintem már csak emiatt sem lehet azt mondani, h a ruby a legjobb, legfeljebb azt, h személy szerint nekem bejön, vagy nem jön be. kinek a pap, kinek a papné. az összes divatos nyelv, vagy eszköz rendelkezik kellő támogatottsággal. ezért a csapat felkészültsége, lelkivilága a döntő szempont.

elméletileg az összes nyelv alkalmas webfejlesztésre. még a forth is. persze az igaz, h zéró körüli a támogatottsága. de elméletileg lehetne azzal is weboldalakat gyártani. csak nyilván nehéz lenne megfelelő embereket találni.

Igen, elméletileg az összes nyelv alkalmas webfejlesztésre, mégis relatíve kevesen fejlesztenek webre assemblyben avagy brainfuckban. És nem csak azért, mert nem jól támogatottak, hanem mert kevésbé kifejezőek.

Én a Rubyt nem ismerem, de biztos van benne egy-két feature, ami pl. PHP-ban nincs. És pont ezért nem fog hiányozni annak, aki csak PHP-ban kódolt...

Vannak jobb nyelvek, és vannak kevésbé jók, és ez nem csak a támogatottságon múlik.

Ha ez most nem volt elég meggyőző, olvassátok el ezt:
www.paulgraham.com/avg.html

a külső támogatottságon és belső meggyőződősen múlik. de ha a lexikális felépítést széjjelelemezzük, akkor azt kapjuk, h nyelvek között nincsenek lényeges különbségek, egy nyelvi elem hiánya önmagában még nem jelent hátrányt.

itt van a tegnapi google chart deklaráció. vessünk már rá egy pillantást.

img src=chart.google.com?par1=val1&par2=val2 width="300px" height="100px"

az url-t fogjuk fel úgy, mint egy webszolgáltatás, a paraméterek a tartalmat meghatározó elemek, amelyek el vannak választva a formai jegyektől. az url-ek mint szolgáltatások hierarchiába rendezhetők, és jelölő elemekkel egymásba ágyazhatók. minden url-hez kapcsolódhat valamilyen autentikáció.

elég szofisztikált szemlélet ez, és a programozási nyelvek lózungai nélkül értük el. ez egy közönséges html deklaráció.

érvelhetnék úgy is, h nyilván a hülyéknek kellenek a nyelvi mankók, ez persze nem igaz. a vannak akik az egyszerűbb nyelveket részesítik előnyben, vannak akik a bonyolultabbakat, és vannak olyanok is, akik azt mondják, vsecko jedno. azért, mert a többféle környezetben képesek szofisztikáltan programozni, vagy pont azért mert semmilyen környezetben nem képesek.

persze aki abban akar hinni, h csak a ruby, az higgyen abban, szerintem a helyes az, h a kellő támogatottsággal rendelkező eszközöket a csapat áttekinti, aztán kiválasztják azt az eszközt, amelyik számunkra a legszimpatikusabb. és ha ez a ruby, akkor azt, ha a php, akkor azt.

sose láttam Rubyt, csak arra reagálnék, amit Aadaam 2007.12.08. 21:02:05 belinkelt.
ha jól értettem a faszit, aki visszaváltott PHP-ra, akkor a Ruby ugyan sok mindent kitalált, de kitalálta egyféleképpen, és aztán azt mondja, hogy neked MUSZÁJ aszerint csinálnod. hát ez erősen emlékeztet az SAP-ra, meg a hajvágógépre*. az SAP-t pedig ismerem egy kicsit, és azt mondom: nagy cégeknek, nagyon bonyolult feladatra, ahol muszáj, hogy ne dőljön be, viszont elégséges eredmény is jó; na oda ilyen kell. de a WEB fejlesztések 95%-a nem éri el ezt a szintet, beleértve egy egész facebookot is. ha pedig még túlzásba is vitték ezt a szemléletet a Rubynál, akkor pedig a WEB ADA-ja lesznek (végig feltételes mód van).

a REST-es cikkhez: nekem úgy tűnik, hogy a faszi feltalálta Chomsky 3-as típusó nyelvét, és hozzá az állapot-átmenetes automatát. kár, hogy az már 30+ (40+?) éve megvan. de ha ez már túl régi, akkor a teljes event-alapú alkalmazásfejlesztés a 80-as, 90-es évekből már biztos mindenkinek ismerős; az összes op.rendszer eszerint működik. és persze a WEB is, de ezért én még nem értem, hogy ebben mi ér egy PhD-t.

*hajvágógép: egy ember bemegy a találmányi hivatalba:
-jó napot, feltaláltam a hajvágógépet, kiváltja a fodrászok minden munkáját, 5 perc alatt levágja bárkinek a haját.
-remek, látom a leírást, csak egy kérdésem lenne, ami nem világos: hogyan kezeli a gép azt a problémát, hogy minden vendégnek különböző a feje?
-először kérem, először...

Én a többes szám / egyes szám natív angol nyelvű kezelésénél sírtam el magam a Rails ActiveRecordsban, és ott, a Hype ellenére fel kellett hogy adjam. De a nyelv klassz, csak annyira morfékony, hogy kemény projekt megérteni másnak a munkáját. Nem olyan szigorúan elegáns mint a java, és nem olyan kényelmesen rapid & trehány mint a PHP. Viszont a threadkezelés miatt valahova a kettő közé befér.

Átolvasva a kommenteket annyival kiegészíteném az eddig elhangzottakat, hogy igazából nem a nyelv szintaxisa, stílusa a lényeg sohasem (az vallási, ill. izlés kérdése), nem is a Runtime Env., stb stb, hanem elsősorban a hozzáadott kütyümütyük mennyisége határozza meg, hogy mennyire lesz _elterjedt_. PHP-hoz trilliárd kütyümütyü jár egy alap fordítás mellé, és még szét lehet küldeni jól. Java ugyanez elegáns-szigorúban, emiatt jól használható enterprise szabvány mobiltól skálázható nagyszerverekig. Ruby még fiatal, és sok ígéretes móka van már hozzá, de még nem elég talán. Bővebben: www.google.com/search?q=ruby+to+php&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enHU215HU215

Ha a fentebb linkelt Paul Graham féle Beating the Averages cikk megfogott vkit, annak ajanlanam figyelmebe:
seaside.st/
Itt van ket, ezzel a keretrendszerrel keszult alkalmazas demo videoja:
dabbledb.com/explore/7minutedemo/
www.cmsbox.com/video.html

"igazából nem a nyelv szintaxisa, stílusa a lényeg sohasem (az vallási, ill. izlés kérdése)"

A lényeg miben?

Art Mooney, es a tobbiek: eleg rovidlato manager az, aki azert valaszt PHP-s embereket, mert azok olcsobbak, hisze tobben vannak mert kevesebb tudassal is el lehet lavirozgatni. Egy igazan jo fejleszto akkor is X forintot ker, ha PHPben dolgozik, meg akkor is, ha Ruby-ban. Szoktak azt is mondani, hogy a project ktg-einek 20%-a a fejlesztes, 80% a karbantartas. Namost ha dilettansokkal lefejlesztetsz egy rendszert 'olcson', akkor aztan igazan jol jartal. Arrol nem is beszelve, hogy egy dolog az oraber, es egy masik dolog a fejlesztes vegosszege. Mezitlabas PHPvel eltart egy darabig, amig akar egy sima listazast csinalsz adatbazisbol. Ez Djangoban pl. nehany sor kod. (Gyakorlatilag ledefinialod a schemadat pythonban - ezt ugye PHPnal sem uszod meg - es kesz is vagy.) Gondolom RoR-nal is hasonlo a helyzet.

Tobb tiz/szaz teszetlehetlen PHP scriptet nem neveznek szoftvernek (teszteles alatt nem azt ertjuk, hogy Marineni a QA reszlegrol vegigkattintgatja a fontosabb linkeket).

Nemtom ki irta, de nem igaz, hogy a Python ne lett volna ismert a RoR elott, mint web fejlesztesi nyelv. A RoR az elso elterjedt Ruby web framework, de Python ala mar nagyon regen voltak ilyenek. Lasd pl. Zope, ami egy komplett alkalmazas szerver. (Sose hasznaltam, de ettol meg Java fejlesztokent is hallottam rola.) Az mas kerdes, hogy nyilvan nem csaptak ekkora zajt a pythonos fiuk, mint a RoR-es csokak. Es a zajhoz kepest talan elfogadhato az ertekeles, hogy nem tortent semmi.

atleta.hu:
Nem vagyok manager, lehet ez a gond, de szerintem nem az a lényeg, hogy egy fejlesztő nettó x-et kér php tudásáért, és nettó x*2-t a rubyért.
Hanem valahol ott lehet a kutya elásva, hogy egy kis projekthez, ami csak pár év alatt hoz x millió hasznot, inkább keresel egy basic php fejlesztőt, aki semmi máshoz nem ért. Lehet nem lesz szép a kód, sőt lehet lassan fejleszt (ettől még lehet, hogy kevés lesz benne a bug), de így is jobban jársz, mintha alkalmaznád a masterkódert, aki gyorsan és ügyesen megírja, de háromszor annyiért.

atleta:

"eleg rovidlato manager az, aki azert valaszt PHP-s embereket, mert azok olcsobbak"

nem pont ezert, es nem csak ezert. egyszeruen bekerul a kalapba par nyelv, ami szoba johet (pld. php, ror, perl), es mindegyiknek megvan az elonye es hatranya, foleg ha van mar egy csapat, amelynek tagjainak van elokepzettsege/preferenciaja.

+ ahogy masok is irtak, a tamogatas nem csak hr-es fronton szamit, de a kiegeszitesek teren is, ahol detto vezet a php.

persze ettol meg lehet a ror szebb bizonyos managereknek/kodereknek, sot lehet befuto bizonyos projektekben.

"Egy igazan jo fejleszto akkor is X forintot ker, ha PHPben dolgozik, meg akkor is, ha Ruby-ban."

ebben szvsz nincs igazad, pontosan azert, mert ha dolgozik x ft/ho fizuert php-ben, es lat egy ror-os allashirdetest, akkor hulye lesz x ft/ho fizut kerni, amikor tudja, h eleg keves ror-os emberke van, plane profi.

"Namost ha dilettansokkal lefejlesztetsz egy rendszert 'olcson'"

ez csusztatas. az h a php-fejlesztokbol nagy a kinalat es ezert lemegy az aruk, nem jelenti azt, h az olcso php-s fejlesztes dilettansok alkalmazasaval jar.

"Mezitlabas PHPvel eltart egy darabig, amig akar egy sima listazast csinalsz adatbazisbol. Ez Djangoban pl. nehany sor kod."

newsflash, nem muszaj notepaddel 0rol indulni egy php-s projektben, mara mar vannak framework-ok (pld. cake), amiben ez nem (sem) tart sokaig.

"Tobb tiz/szaz teszetlehetlen PHP scriptet nem neveznek szoftvernek"

newsflash, nem muszaj dilettansokat kontroll nelkul alkalmazni. megj. vszleg dilettans ror-os emberkekkel ror-os kod is lehet tesztelhetetlen (meglepo modon).

btw, ismer vki sikeres ror-fejlesztest Mo.on?

Szigorúan a kérdéseidre válaszolva, HH, mivel az ostoba vitába nem fogok belefolyni. Sok olyan ember papol össze-vissza, akiknek zéró közük van a Rubyhoz vagy a Railshez (két teljesen külön dolog egyébként).

"Milyen feladatokhoz használják ezt a keretrendszert?"

Tulajdonképpen mindenhez, ami nagyobb volumenű. A hosting miatt kicsi, jórészt statikus, némi includeal füszerezett projektekre természetesen nem éri meg használni, de afölött szinte mindenre.

Csak egy példa, de rettentő jó a mikroformátum kezelése (kontrollerekben a responds_to?), ezért nagyon egyszerű és hatékonyak benne a keresztplatformos fejlesztés (telefon, pc, pda, etc.), ami ugye manapság kezd alap elvárássá válni.

"Miért éppen ezt?"

Mert egy olyan alkalmazást, amit korábban phpban 4 emberrel 3 hónapig heggesztettél, ezzel 2 emberrel nem tartott egészen 2 hónapig.

Persze ez szubjektív, lehet ezen vitatkozni, hogy biztos a tapasztalat / a jobb speckó / az aranyhal miatt, de szerintem felesleges.

A Rubynak durva előnye van a PHP-val szemben kifinomultság, szintaktikus cukor és elegancia terén és ha elkezded használni, a saját stílusodon is ezen vonások fejlődését veszed észre, ami jó dolog.

A kód olvasható, sokkal egyszerűbben karbantartható, ha egy laikust leültetsz egy "objektum.csinalj_valamit hacsak masik_objektum.volt_hiba?" sor elé, még ő is megérti.

A Rails előre beállítva érkezik, mindenre van szinte megoldása, de ha ez neked nem tetszik, kicseréled az adott részt. Nagyszerű plugin architektúrája van, mindezekmellett relatíve kevés kódból tudsz kihozni olyan dolgokat, amit phpben vagy javában csak sokkal terjengősebben lehetett volna megoldani.

Folytathatnám egyébként még sokáig, de teljesen felesleges. A lényeg, hogy jóval fejlettebb, mint bármelyik php-s framework és a Ruby jóval fejlettebb, érettebb és teljesen más filozófiájú mint a php.

Ezeket a dolgokat a php-s kollégák úgysem fogják addig megérteni / értékelni, amíg huzamosabb ideig nem dolgoznak Rubyval.

Nyilván mindenki azt szereti és abban dolgozik, ami neki biztonságot nyújt, vagy amiben elvárják és ez így van rendjén (én is dolgozom php-ban, ror előtt is abban dolgoztam sok-sok évig), csak a nyitottság hiányzik sokakból és a hype miatt már eleve prekoncepcióval állnak a dologhoz, hogy a java fanatikusokról már ne is beszéljek :)

"Mit vártak a 2.0-s verzió megjelenésétől?"

Semmit igazából, folyamatosan nyomon követtük a commitokat, és már pár hónapja a leendő 2.0-ás trunköt használtuk, szóval nem okozott igazán meglepetéseket. Persze mi bátrak vagyunk :)

"és mit takarnak pontosan azok a bűvszavak, hogy REST vagy ActiveResource?"

A REST-re már korábban megadták a választ, az ActiveResource pedig a Railsen belüli megvalósítása, az eddigi SOAP szerű szar helyett.

Még nem próbáltam ki, ezért véleményt nem alkotok róla.

Egy szó, mint száz: sok-sok mindent hozott a RoR és a Ruby, a sok hiányosság mellett rettenetes fejlődésen ment át mindkét dolog az utóbbi időben (lessétek meg a Ruby 1.9 teljesítménymutatóit a jelenlegi stabilhoz képest). Külföldön nagyon sokan használják, konferenciák garmada, hosting cégek garmada, júzer groupok tömkelege nyílik, pörög mindenhol.

Csak itt nálunk, az 5 éves lemaradás vastag leple alatt vizsgálva nem tűnik ez olyan erősnek, de ami késik, nem múlik :)

a 7 reasons I switched back to PHP cikk 6. pontján sírtam magam könnyesre.

"#6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables.
I was always fighting against Rails and its migrations hiding my beloved SQL from me."

csodálatos. komolytalan az egész cikk.

majke: ha a fejleszto szabadon valaszthat platformot, miert ne olyat valasszon, ami NEKI tetszik? _barmi_ is legyen az oka.

a cikk cime "7 reasons I switched back to PHP", nem az, h "7 reasons EVERYONE SHOULD switch back to PHP". eh.

teljesen igazad van, mindenki abban kódol, amiben csak akar.

amiért kikeltem az az, hogy az oreillynet-től komolyabb dolgokat szoktam meg. ezzel az erővel azt is írhatta volna, hogy nem tetszik, hogy a rails elfedi a gép kódot előle, vagy elesik a lehetőségtől, hogy személyesen magnetizálhassa a vinyóra a kódját.

ismétlem, mindenki abban kódol, amit akar. de nehogymár negatívum legyen az, hogy a kóder elől elfedi a keretrendszer az adatbázisréteget. az ilyen emberek által kiadott munkákban szoktam látni nyitóoldalon a kiescape-lt spéci karaktereket :)

majke: no azert jopar embernek kozeli baratja az sql, es ezek utan megszokni pld. egy ilyet:

array
("Author.name" => "Bob", "or" => array
(
"Post.title" => "LIKE %magic%",
"Post.created" => "> " . date('Y-m-d', strtotime("-2 weeks")
)
)

hm.. en is tuzet fujnek ha kotelezo lenne hasznalnom :)

az escape-elessel kapcs. megjegyzesed amugy elegge inkorrekt. nincs osszefuggesben az, h vki felfogja-e az escape-elest es kepes implementalni azt ill. h sql-t hasznal v egy azt elfedo layert. (hacsak ugy nem, h aki keptelen felfogni ezt, az kenytelen lesz layert hasznalni :))

hát, én már cseréltem mysql-t postgres-re más által megírt portál alatt, és igencsak örültem volna egy rétegnek, amit csak át kellett volna írnom/configolnom, mint egyesével az összes query-t tesztelni/cserélni a kódban. de ez már nagyon off :)

viszont kezdek mérges lenni. a core rails-ből egy csomó mindent kiszedtek, és pluginba tettek. viszont erről sehol nincs egy összefoglaló oldal, hogy miket nem találok meg ezentúl és helyettük mit kéne telepítenem...

> ebben szvsz nincs igazad, pontosan azert,
> mert ha dolgozik x ft/ho fizuert php-ben, es
> lat egy ror-os allashirdetest, akkor hulye
> lesz x ft/ho fizut kerni, amikor tudja, h
> eleg keves ror-os emberke van, plane profi.

Profi PHPsbol is keves van. A lenyeg pont ez. Nem igazan a nyelv szamit, hanem a szaktudas. (Persze ez is csak reszben igaz, mert pl. javas projektekre magasabb osszegeket el lehet kerni. Ugyanakkor azok _nagy resze_ nagyobb volumenu, mint a RoR/PHP.)


>> "Namost ha dilettansokkal lefejlesztetsz egy
>> rendszert 'olcson'"
> ez csusztatas. az h a php-fejlesztokbol nagy
> a kinalat es ezert lemegy az aruk, nem

Ez nem igazan csusztatas, ha figyelembe veszed, amit az elozo par sorban irtam (hogy szerintem a jo PHPs fejleszto kozel olyan draga, mint a jo RoR fejleszto), meg azt amire reagaltam (azert olcsok a PHP fejlesztok, mert kevesebb tudassal is neki tudnak allni).

>> "Mezitlabas PHPvel eltart egy darabig, amig
>> akar egy sima listazast csinalsz
>> adatbazisbol. Ez Djangoban pl. nehany sor kod."

>newsflash, nem muszaj notepaddel 0rol indulni
>egy php-s projektben, mara mar vannak
> framework-ok (pld. cake), amiben ez nem (sem)
> tart sokaig.

Hat te nagyon readonly vagy. Az elso hsz-emben - amire te reagaltal - irtam en is, hogy van olyan, hogy CakePHP. Es azt pont annyi munka megtanulni es megerteni - gondolom - mint a Rails vagy a Djangot vagy a megfelelo Javas frameworkoket. Tehat nem az olcso PHP script kiddie kategoria. Gondolom Cake fejlesztobol sincs olyan nagyon sok.

> newsflash, nem muszaj dilettansokat kontroll
> nelkul alkalmazni. megj. vszleg dilettans
> ror-os emberkekkel ror-os kod is lehet
> tesztelhetetlen (meglepo modon).

Nyilvan. A kontrollal nem sokra mesz, ha hianyzik a tudas es a _hozzaallas_. Akkor oda kell allitanod egy korbacsos urget minden fejlesztod moge. Raadasul a korbacsos urgenek (hivjuk peer reviewernek) ertenie kell a dologhoz, tehat azzal egy jo ember erofirrasait kotod le.

Amugy tovabbra sem szamolod bele, hogy nem az oraber szamit, hanem az elkeszult alkalmazas vegso ara (mondjuk oraber*emberora).

> btw, ismer vki sikeres ror-fejlesztest Mo.on?

Miert, sikeres fejleszest ismer valaki? :)) (Ja, es en nem vagyok egy kifejezett RoR hivo, magat a nyelvet se birom. Ha mar script, akkor nekem inkabb python.)

off

azert a fenti pelda sztem siman felrevezeti azt, aki sql-bol erkezik egy ilyen fele. az sql jellemzoje, h felolvasva a statement-et van ertelme, a fentire viszont ez nem igaz..

on

Watchman:
> Nem vagyok manager, lehet ez a gond, de
> szerintem nem az a lényeg, hogy egy fejlesztő
> nettó x-et kér php tudásáért, és nettó x*2-t

Igy van, en is ezt mondom. A vegosszeg szamit. Pont. BTW egy produktivabb kornyezetben dolgozo (vagy szimplan csak produktivabb) fejleszto kerhet magasab orabert ugy, hogy kozben meg mindig olcsobban csinalja meg az adott munkat.

> millió hasznot, inkább keresel egy basic php
> fejlesztőt, aki semmi máshoz nem ért. Lehet
> nem lesz szép a kód, sőt lehet lassan
> fejleszt (ettől még lehet, hogy kevés lesz
> benne a bug), de így is jobban jársz, mintha
> alkalmaznád a masterkódert, aki gyorsan és
> ügyesen megírja, de háromszor annyiért.

Mondjuk en sem vasarlok kodolokat (egyelore), inkabb a masik oldalon allok, de azert ez igy egy kicsit le van egyszerusitve. Ugye van az a legenda, hogy a jo es az atlagos programozo kozott van egy 10x produktivitas beli kulonbseg. Ha nekem egy profi megcsinal valamit 2 het alatt, amit egy kepzetlen urge harmadakkora oraberrel 3 honapig fejleszt, akkor nem kerdes, hogy kivel jarok jobban. (Plane, hogy meg elobb kesz is van a cucc. Plane, hogy a dilettans modon osszerakott cuccot utana nehez lesz karbantartani.) Persze ha mindketto egyforman jo, akkor nem kerdes, hogy az olcsobbat kell valasztani. A tobbi esetben mar bonyolultabb a dontes.

off


szerinted ezt nem lehet első olvasásra megérteni?


posts = Post.find( :all, :conditions => { :type => 'blogpost' }, :limit => 10, :offset => 0 )

on

amúgy meg a finder-nek simán át lehet adni Time típusú objektumot, simán és jól dátummá parse-olja :)

szóval elrettentésként én is tudnék rettentő csúnya sql-t írni, csak minek? :)

majke: ez egy primitiv statement, az meg szinte minden megoldasnal jol olvashato. inkabb azt ird le, h hogyan kodolod le azt a feltetelt, amit a 2007.12.10. 15:12:12 -es postban irtam, mondjuk ugy h a "magic" stringet parameterkent kapod es a ui-rol csepelte be vki.

spec a statementedet kurvára nem is értem, szintaktikán kívül ennek nem sok köze van a railshez :)


de mondjuk az ui-ról kapott magic szóra LIKE-kal rákeresni emígy

Post.find( :all, :conditions => [ "title LIKE ?", "%#{params[:from_ui]%"] )

a dátumos feltételre meg mint írtam elég egyszerű a megoldás:
:conditions => [ "date < ?", Time.now-1.day ]

Az SQL-nek semmi köze a Railshez, se a Rubyhoz. SQL-t mindenhol lehet írni, ha te arra vágysz.

Az ember nem azért használ ORM-et, mert rá van kényszerítve. A szintaktika / megvalósítás az ORM sajátja, ha neked ez tetszik / megkönnyíti a munkádat, használod. Ha az SQL-t szereted, akkor írod az SQL-t.

# Post.find_by_author("Bob", :conditions => [ "title LIKE ? and date < ?", params[:ui], 2.weeks.ago])

# Post.find_by_sql ["SELECT p.* FROM posts AS p INNER JOIN authors ON (authors.id = p.author_id) WHERE p.title LIKE %#{params[:ui]% AND p.date < #{2.weeks.ago}]

Ennyi, innentől fogva te döntöd el, melyiket használod, szíved joga.

Viszont a Railsnek, Rubynak és PHP-nek ehhez az égvilágon semmi köze. Akár PHP alatt is használhatod az AR-t, akár írhatsz SQL-t is.

Ha már vitatkozni próbálsz, akkor legalább ne keverd a szezont a fazonnal, szerintem :)

Fentiekhez hozzátartozik, hogy a példa rettentően alap szintű, egy komolyabb alkalmazásban soha nem használod így, se a find_by_sql-t se az AR findereket ...

Még valami, amit eddig nem emített senki: a Rails szuperül használható prototípusok elkészítésére, hiszen helyesen használva a produktivitásod és a fejlesztés sebessége messze meghaladja mondjuk egy PHP, vagy Java alkalmazás fejlesztését.

Sok esetben még az is kifizetődő, hogy a Railsben egy core team által legyártott alkalmazás prototípust újraírnak PHP-ben vagy akármilyen más környezetben, ha ezt az alkalmazás mérete, vagy akármilyen külső indok megköveteli.

A rails egy framework, a php egy script nyelv, amiben tetszoleges framework-ot lehet irni. A ruby es a php hasonlithato ossze. Ha csak ezt nezzuk, akkor nem sok erdemi kulonbseg marad, talan csak annyi, hogy a php sokkal altalanosabb es megengedobb tobbfajta stilussal szemben. A ruby meg koveti a sajat eszjarasat. Hasznalni mindkettot lehet, bar a php-hoz sokkal tobb kesz kod es modul van, ami elony tud lenne ha gyorsan kell valamit osszehozni.

kvp : "A ruby es a php hasonlithato ossze. Ha csak ezt nezzuk, akkor nem sok erdemi kulonbseg marad"
Mennyit programoztál ruby-ban? Csak azért kérdezem mert a két nyelv alapjaiban tér el egymástól és nem tudom mi alapján vontad le ezt a következtetést.

Találtam pár érdemi hozzászólást amiért érdemes volt elolvasni a comment-eket, de azt nem igazán értem hogy emberek miért bonyolódnak szakmai vitákba olyan témákban, ahol az első 2 mondat alapján eldönthető hogy a mondanivaló mögött nincs érdemleges tudás és/vagy tapasztalat.
Talán három embert sikerült összeszámolnom akik úgy szóltak a témához, hogy látszik hogy használták már a ruby-t / rails-t valamire.

Emellett mindenkinek aki komolyan foglalkozik programozással érdemes minél több programnyelvvel megismerkednie, mert mindegyikből lehet tanulni és nagyon jól tudja a látókört szélesíteni, vagy szemléletmódot formálni. Én személy szerint a Pythont és Django keretrendszert fogom megnézni pusztán szakmai kiváncsiságból. Így aki web-es fejlesztéssel foglalkozik annak tényleg bátran ajánlom hogy egy kicsit ássa bele magát a ruby on rails-be. Nagyon sokmindent lehet tanulni belőle amit hasznosítani lehet bármilyen nyelven is dolgozzunk.

"Ha csak ezt nezzuk, akkor nem sok erdemi kulonbseg marad, talan csak annyi, hogy a php sokkal altalanosabb es megengedobb tobbfajta stilussal szemben."

Húha... talán nem kéne terjeszteni az ilyen "szakmai" megjegyzéseket...

Még annyit tennék hozzá ehhez az open th...ahhoz, hogy ha jól tudom/érzem (meg ahogy velem is történt), először a Prototype keltette fel a szélesebb közönség érdeklődését, rengetegen e JS keretrendszeren keresztül ismerték meg a Railst és a Rubyt is. Mondanom sem kell, hogy a Prototype az AJAX érában és a JS történetében mérföldkőnek számít; a kódjában a fejlesztői társadalom egy emberként kezdett el gyönyörködni. Megmutatta, milyen őrült jó megoldások vannak a Rubyban, merthogy ez voltaképp egy Rubyra hangolt JS implementáció, s nem utolsósorban megmutatta azt is, hogy a JS olyan nyelv, amivel ezt meg lehet tenni.

még valami eszembe jutott: volt valaha régen egy kis humoros írás az 'Igaz programozó'-ról. aki tetszőleges programnyelven tudott Fortrant programozni, meg 16MB-os hexa dumpban hibát keresni. minden programozási feladathoz hozzá lehet állni ilyen 'Igazi programozó' stílusban.

egy kicsit a PHP esetén azt érzem, hogy persze, a PHP engedi, hogy írjál 200 sorban valamit, majd írjál még 50-et hozzá, meg még egy funkciót, meg még egy oldalt, meg még egy kis AJAX-ot, aztán nagy sártapasztás lesz az egész. na de a Windows kódja, amit biztosan nem PHP-ban írtak, az milyen? meg az Office? meg az SAP? miért kellett nekiugrani az új Windows kernelnek a semmiből? pont ezért, mert nem voltak megtervezve, illetve nem ekkorára voltak tervezve, és a határidó miatt sártpasztás az egész kód.

de ha rendesen meg van valami tervezve, és probléma estén rendesen áttervezik (rászánják az időt és energiát), akkor tök mindegy, hogy miben van. az egyetlen kérdés, hogy elég erőteljes-e egy nyelv. és bármelyik nyelv jó, amelyik elég erőteljes, feltéve, hogy tudással is felszerelkezett programozók, és nem csak tapasztalt kódolók írják a programot.

hát igen, ezt adta nekünk a Ruby on Rails ... egy olyan webes fejlesztőrendszert amire a php-s kollégák ennyire érzékenyen reagálnak.

meghalt a király, éljen a király!

"az egyetlen kérdés, hogy elég erőteljes-e egy nyelv"

FLAME ON
És ez mit jelent? Mihez elég erős? Pl. Ez
dabbledb.com/explore/7minutedemo/
Smalltalkban készült, és szerintem nem nagyon lehetne PHP-ban megcsinálni, talán még RoR-ban sem.
FLAME OFF

"Emellett mindenkinek aki komolyan foglalkozik programozással érdemes minél több programnyelvvel megismerkednie"
A fenti alkalmazás egy Seaside nevű open source Smalltalk alapú keretrendszben készült. Ha valaki ki akarja próbálni:
1. Itt lehet letölteni a környezetet: www.seaside.st/resources/distributions/Seaside-2.8-final.app.zip
2. Ebből a könyvből meg lehet tanulni Squeak Smalltalkban programozni: www.iam.unibe.ch/~scg/SBE/SBE.pdf
3. Itt egy Seaside tutorial: www.swa.hpi.uni-potsdam.de/seaside/tutorial

szerintem nem flame megkérdezni, hogy mi az, hogy erőteljes egy nyelv, van is rá válasz: rendelkezik azokkal a nyelvi konstrukciókkal, amelyekkel azok a programozási feladatok, amikre szánták, hatékonyan megoldhatók.

ez a válasz persze még magyarázatra szorul, mert túl tömör. elméletileg pl. a C erőteljes nyelv, mert nem tudsz olyan feladatot mondani, ami C-ben ne lenne leprogramozható. de persze az álljon neki pl. webalkalmazást C-ben fejleszteni, akinek két anyja van (egyébként meglepődnél, hogy egy-két könyvtárat kellene csak összedobni, és ott lennél a PHP-nál).

azaz a hatékonyság jön be mint kérdés. a hatékonyság pedig két elemből áll össze: a nyelv specializáltsága (pl. webalkalmazás esetén HTTP requestek, SQL queryk stb,-k kezelésének támogatása) és a nagyobb léptékű rendszerekre vonatkozó elméletek (többrétegű alkalmazás, komponens alapú fejlesztés, objektumok bezárása, modulstruktúra stb.) támogatása. mindkét elem egyszerre áldás, és egyszerre átok: az előnyért döntéseket kell hozni (mert mindenőtt több alternatíva adott), azaz más utakat, más megoldásokat el kell vetni.

tehát az erőteljesség kérdése kétféleképpen tehető fel: általános nyelv esetén melyik a legerőteljesebb; és egy konkrét feladatosztályra vonatkozóan melyik nyelv a legerőteljesebb. lambda teóriára sose fogsz a LISP-nél jobbat mutatni; a PROLOG verhetetlen reduktív következtetésekben, és szabályalapű reprezentációban. ha pedig sturkturált és erősen typusos programozást akarsz oktatni, akkor Modula2-t válassz (sajnos nem terjedt el).

de azért megismétlem, hogy szerintem nem ez tűnik a legfontosabbnak. a tervezés sokkal fontosabb (semmilyen keretrendszer nem váltja ki). meg az, hogy a szintaxison még class-hierarchián túli tudással is rendelkező emberek gyártsák a kódot.

PS: aNick: megnéztem a demo-t, rendkívül impresszív relációs adatmodell-manipulációs eszköz, de pontosan mit nem lehetne megcsinálni ebből akár C-ben is? esetleg arra gondolsz, hogy ez a rendszer saját, beépített adatbáziskezelővel rendelkezik (mint a MS Access), és ezért nem kell bele SQL elérési könyvtár?

"megnéztem a demo-t, rendkívül impresszív relációs adatmodell-manipulációs eszköz, de pontosan mit ne lehetne megcsinálni ebből akár C-ben is?"

A DabbleDB egy webes alkalmazás, mezei usereknek, excel helyett. Ki lehet próbálni élőben is:
dabbledb.com/signup/
Te írtad, h C-ben nem jó webes alkalmazást fejleszteni. Én azt mondom, h ilyet még Rubyban Railsszel se, ehhez Seaside és Smalltalk kell. No ez a flém.

aNick: "Smalltalkban készült, és szerintem nem nagyon lehetne PHP-ban megcsinálni, talán még RoR-ban sem."

Nagy levegő, sóhaj, és nem írok semmit....