Archief - DISCUSSIE: Ruby, Rails, etc.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Radiance
Legacy Member
Goh ik heb er wel eens mee gespeeld en imho is het toch vooral een mode speeltje. Voor RoR werkte, bij mijn weten, amper iemand met Ruby in webdevelopment zelf en ik kan mij dan ook alleen maar voorstellen dat daar soms bouwvallige projecten uitkomen, omdat mensen niet altijd volledige kennis hebben van de taal, de omgeving en hoe je er bv. veiligheid in steekt.
Er zijn ook zulke frameworks voor bvb. PHP ( Symfony ) en als je al vertrouwd bent met een taal lijkt het mij interessanter om daar op door te gaan.
My 2 cents
Er zijn ook zulke frameworks voor bvb. PHP ( Symfony ) en als je al vertrouwd bent met een taal lijkt het mij interessanter om daar op door te gaan.
My 2 cents
KevinMa
Legacy Member
Als we zien waarvan Ruby en RoR komen, en waar het naartoe gaat, denk ik dat we moeilijk van een mode speeltje kunnen spreken (cfr. JRuby, YARV, Mongrel, ...).
Met Symfony heb ik geen ervaring, maar frameworks zoals CakePHP en CodeIgniter geven me meer de indruk een Rails kloon te willen zijn; kost wat kost het op dezelfde manier als Rails willen doen ipv aan een betere PHP implementatie te denken.
Wat mij ertoe drijft Ruby on Rails te gebruiken is niet niet zozeer Rails zelf, maar Ruby is gewoon een taal die, mijns inziens, prettiger werkt dan PHP. Wil ik een login systeem met rails, dan installeer ik gewoon een gem met rubygems en binnen de 5 minutes kan ik inloggen, migrations voor de tables gegenereerd zodat ik ook gemakkelijk kan deployen.
Het is toch wel wat teleurstellend dat Belgie hier wat achterop blijkt te hinken.
Ik denk ook dat vele mensen Ruby en Rails onlosmakelijk aan elkaar verbonden zien, terwijl er ook alternatieven zijn, kijk bijvoorbeeld naar Merb en DataMapper. Rails is ook veel meer dan de bekende "blog in 15 min" en dan maar scaffolden (ik gebruik het zelden tot nooit).
Met Symfony heb ik geen ervaring, maar frameworks zoals CakePHP en CodeIgniter geven me meer de indruk een Rails kloon te willen zijn; kost wat kost het op dezelfde manier als Rails willen doen ipv aan een betere PHP implementatie te denken.
Wat mij ertoe drijft Ruby on Rails te gebruiken is niet niet zozeer Rails zelf, maar Ruby is gewoon een taal die, mijns inziens, prettiger werkt dan PHP. Wil ik een login systeem met rails, dan installeer ik gewoon een gem met rubygems en binnen de 5 minutes kan ik inloggen, migrations voor de tables gegenereerd zodat ik ook gemakkelijk kan deployen.
Het is toch wel wat teleurstellend dat Belgie hier wat achterop blijkt te hinken.
Ik denk ook dat vele mensen Ruby en Rails onlosmakelijk aan elkaar verbonden zien, terwijl er ook alternatieven zijn, kijk bijvoorbeeld naar Merb en DataMapper. Rails is ook veel meer dan de bekende "blog in 15 min" en dan maar scaffolden (ik gebruik het zelden tot nooit).
virox
Legacy Member
'k ben nu al 2tal maand in Ruby on Rails aan het prutsen. 'k moet zeggen 't is een intressant framework. Al paar keer voor gehad dat ik een probleem had en dat ik het veel te ver zocht, sommige dingen zijn echt belachelijk eenvoudig
't is wel leuk en heeft zeker potentieel op te groeien tot een veel gebruikt framework.
't is wel leuk en heeft zeker potentieel op te groeien tot een veel gebruikt framework.
Radiance
Legacy Member
Ik vind het een beetje vreemd dat je nu net zegt dat je de scaffolding niet gebruikt. Dat leek mij nu net een van de voordelen Dat kan overigens ook met Symfony, die ik nu zelf net de het dichtste bij RoR vind aanleunen.
Kleine projectjes maak ik tegenwoordig (enfin, doe eigenlijk al een half jaar geen webdev meer) in het Zend Framework, die imho juist wel een php-eigen implementatie maakt en ze raken stilaan uit het beta stadium (niet zo zeer qua code kwaliteit, die was altijd best al goed, maar interface changes die nog regelmatig voorkwamen in vorige releases).
Tekortkomingen : het model gedeelte van MVC is maar heel beperkt geimplementeerd.
Dat kan overigens ook met Symfony, die ik nu zelf net de het dichtste bij RoR vind aanleunen.Kleine projectjes maak ik tegenwoordig (enfin, doe eigenlijk al een half jaar geen webdev meer) in het Zend Framework, die imho juist wel een php-eigen implementatie maakt en ze raken stilaan uit het beta stadium (niet zo zeer qua code kwaliteit, die was altijd best al goed, maar interface changes die nog regelmatig voorkwamen in vorige releases).
Tekortkomingen : het model gedeelte van MVC is maar heel beperkt geimplementeerd.
taLa.
Legacy Member
Werk al vrij lang met PHP, en de RoR-craze is mij ook niet ontgaan. Ik heb het uitgeprobeerd, en mijn ondervinding was dat het allemaal dik in orde is, zolang ge maar binnen de lijntjes blijft. Altijd kwam ik wel iets tegen dat onmogelijk/onnodig lastig was omdat RoR per sé zodanig veel voor u doet da ge zelf bijna niets meer kunt. Dat is trouwens niet alleen met RoR zo, zie'k ook vaak in andere frameworks voor PHP. Daarom geef ik voor PHP ook de voorkeur aan CodeIgniter omdat die juist niet te uitgebreid is en niet te veel in uw weg komt zitten. Bovendien is RoR ambetanter om mee te werken omdat ge hoe dan ook een shell nodig hebt, en die is vaak niet beschikbaar op webhosts.
Maar in het algemeen ben ik niet zo voor frameworks. Voor Ruby misschien nog wel omdat die taal niet heel web-gericht is en daarom wel wat tools kan gebruiken, maar zelfs in PHP vind ik het nog altijd gemakkelijker om procedureel te werken ipv. via classes en frameworks te werken. Reden: de OOP-faciliteiten van PHP trekken op de ballen, PHP5 is nog altijd niet wijdverspreid genoeg, en ondervinding leert dat alles via classes en OOP doen vaak de dingen onnodig ingewikkeld maakt en bovendien de applicatie een factor trager maakt.
0.02€
Maar in het algemeen ben ik niet zo voor frameworks. Voor Ruby misschien nog wel omdat die taal niet heel web-gericht is en daarom wel wat tools kan gebruiken, maar zelfs in PHP vind ik het nog altijd gemakkelijker om procedureel te werken ipv. via classes en frameworks te werken. Reden: de OOP-faciliteiten van PHP trekken op de ballen, PHP5 is nog altijd niet wijdverspreid genoeg, en ondervinding leert dat alles via classes en OOP doen vaak de dingen onnodig ingewikkeld maakt en bovendien de applicatie een factor trager maakt.
0.02€
infinium.be
Legacy Member
Heb ik maar 1 ding op te zeggen en dat is dat ik het allemaal in PHP doe. Ben min of meer van de mening dat je beter de tijd dat je in het bestuderen van een framework steekt in het zelf ontwikkelen van de functionaliteit steekt.
Wat frameworks betreft heeft infinium.be een huisgeschreven "framework" met volledige AJAX support. (binnenkort ook open source) Maar de dingen die ik daar ooit voor geschreven heb zou ik nu niet meer direct weten hoe te doen.
Maar over het algemeen vind ik "framework" ook maar een buzzword, ze zouden het (in de meeste gevallen) gewoon een library moeten noemen.
UPDATE: Ik had precies meer als 1 ding te zeggen
Wat frameworks betreft heeft infinium.be een huisgeschreven "framework" met volledige AJAX support. (binnenkort ook open source) Maar de dingen die ik daar ooit voor geschreven heb zou ik nu niet meer direct weten hoe te doen.
Maar over het algemeen vind ik "framework" ook maar een buzzword, ze zouden het (in de meeste gevallen) gewoon een library moeten noemen.
UPDATE: Ik had precies meer als 1 ding te zeggen
KevinMa
Legacy Member
Mensen zien de screencast op rubyonrails.org en krijgen de indruk dat Rails gelijk staat aan scaffolding en denken dat ze daartot beperkt zijn, ik zie het meer als een helpend handje bij basic CRUD in bvb een admin panel.Radiance zei:Ik vind het een beetje vreemd dat je nu net zegt dat je de scaffolding niet gebruikt. Dat leek mij nu net een van de voordelen
Bekijk capistrano eens.taLa. zei:
Dan wil ik wel eens de maintainability van een webapp van meerdere KLOC zientaLa. zei:
't Is zo een beetje zoals naar de WC gaan en dan het hele kamertje onderschijten; leuk voor degene die na u komt.
taLa.
Legacy Member
KevinMa zei:Dan wil ik wel eens de maintainability van een webapp van meerdere KLOC zien
't Is zo een beetje zoals naar de WC gaan en dan het hele kamertje onderschijten; leuk voor degene die na u komt.
Valt best mee als ge een beetje ordelijk werkt en de logica gescheiden houdt van de presentatie (Smarty = held). Vanaf dan verschilt het qua complexiteitsgraad eigenlijk niet eens zo veel denk ik. Heel het gedoe rond frameworks en de enorme maintenance-vriendelijkheid die ermee gepaard zou moeten gaan is nogal overrated imo.
Hebt ge voor die capistrano trouwens ni nog altijd shell access nodig? :/
KevinMa
Legacy Member
taLa. zei:
Voor een huis-, tuin- en keuken siteje gaat die redenering misschien op. Ik vermoed dat je nog niet met een echt groot project hebt gewerkt en/of dat je OOP niet/onvolledig begrijpt. Mind you, als je ambities hebt in deze sector ga je met je uitspraken niet de beste vrienden maken
Capistrano was een antwoord op het eerste deel van de zin. Ik heb geen ervaring met ruby webhosts omdat ik met dedicated servers werk, maar het enige dat je moet kunnen doen is eigenlijk het restarten van de mongrel/fcgi processes als de code geupdate is, wat makkelijk een admin panel optie zou kunnen zijn.
taLa.
Legacy Member
KevinMa zei:Voor een huis-, tuin- en keuken siteje gaat die redenering misschien op. Ik vermoed dat je nog niet met een echt groot project hebt gewerkt en/of dat je OOP niet/onvolledig begrijpt. Mind you, als je ambities hebt in deze sector ga je met je uitspraken niet de beste vrienden maken
De typische holier-than-thou attitude van frameworkaanhangers...
Wees gerust, ik heb genoeg ervaring met grote sites, ik begrijp de OO-principes volledig en ben allesbehalve onpopulair in mijn sector. Ik vind de meeste frameworks gewoon te onhandig om mee te werken in een duidelijk niet-OO taal als PHP. Bovendien zijn classes enorm brak geïmplementeerd in PHP, en als je dan toch de OO-filosofie wilt volgen kom ik hoe dan ook tot de conclusie dat de applicatie onnodig veel ingewikkelder en trager is geworden.
Dan vind ik het persoonlijk handiger om de traditionele manier van werken te volgen, weliswaar aangevuld met een omliggende set van OO klassen en tools die hele stukken abstraheren en de algemene structuur verhelderen. Ik verlies veel meer tijd met onnodig gepruts en gehack aan de schots en scheve werking van classes in PHP om toch maar met een OO framework te willen werken dan ik verlies aan onderhoudstijd op de traditionele manier, geloof me vrij.
dJeez
Legacy Member
Je hebt het hier dan wellicht wel over PHP4... Anders mag je het brakke aspect wel eens verder toelichten (want in PHP5 is er toch wel serieus aan gesleuteld geweest). Een OO applicatie is niet noodzakelijk ingewikkelder, althans toch niet als je correct de OO aspecten beheerst en er dus ook correct mee omgaat. Verder zeg je niets over het aspect herbruikbaarheid, laat dat nu net de sterkte van OO en van frameworks zijn.taLa. zei:
Naar standaardisatie van code toe is een framework overigens ook handiger, aangezien het steeds een zekere basis oplegt (wat zowel als voor- als als nadeel kan gezien worden uiteraard). Ik wil (bij wijze van spreken) geen ettelijke uren spenderen aan het ontcijferen van de structuur van de code van een voorganger als dat net zogoed in een oogopslag kan.
En als laatste : je moet het wiel niet steevast proberen opnieuw uit te vinden. Onlangs nog problemen gehad omwille van een kerel die zelf een mailserver had geschreven, maar dan wel de POP3 implementatie niet volledig had geïmplementeerd. Leg dan maar aan de klant uit dat het probleem bij zijn mailserver ligt en niet aan uw applicatie.
BTW Het argument dat je een command line nodig zou hebben voor de frameworks is irrelevant in een professioneel kader. Of gebruik je geen testomgeving (die je zelf volledig in handen hebt) misschien?
taLa.
Legacy Member
dJeez zei:
Bij het brakke aspect denk ik aan dingen als statische methoden die gewoon uitvoerbaar zijn als instancemethoden (kan al tellen als schending van OO-principes imo), compleet scheve statische uitvoeringscontexten bij parent classes, en de bijhorende onvermijdelijke nood aan de functie get_class(). En zo zijn er nog wel een paar obscure bugs waar ik niet meteen op kan komen. Het is duidelijk dat PHP niet gemaakt is voor grote OO toepassingen, vandaar ook mijn keuze voor een combinatie van de klassieke manier aangevuld met OOP-componenten (die overigens sterk overeenkomen met componenten uit frameworks en net zo goed herbruikbaar zijn).
Het opleggen van een zekere basis is trouwens niet noodzakelijk iets dat voorbehouden is voor frameworks. Ook ik heb een basisinfrastructuur van klassen en folders waar ik sites rond bouw. Ook heb ik bij wijze van spreken geen zin om ettelijke uren te spenderen aan het ontcijferen van hoe het gebruikte framework werkt en het doorploeteren van een hiërarchie van 32 klassen om iets aan te passen dat op mijn manier in 2 seconden kan. Allemaal vatbaar voor persoonlijke voorkeur.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.