[ruby on rails] wie gebruikt het?

Pagina: 1 2 3 4 5 Laatste
Acties:
  • 9.058 views sinds 30-01-2008
  • Reageer

Acties:
  • 0 Henk 'm!

Verwijderd

Nou, ik was wat voorbarig sceptisch.
Ik heb het geprobeerd (cookbook) heb ruby beetje bekeken, het rails concept en ben tot de conclusie gekomen dat het echt zeer veel belovend is.
De laatste paar maanden ben ik met mijn collega bezig geweest een vrij grote site in elkaar te proggen. We hebben gelijktijdig een framework ontwikkeld. Alle problemen/voordelen die we daarin tegen kwamen kom ik opgelost en wel tegen in rails. Dat geeft voor mij in elk geval aan dat ze erg goed hebben nagedacht over hun product. Voordeel hierbij is dat het allemaal zeer makkelijk te updaten is. Geen zelf version control, niet uitleggen aan nieuwe collegas hoe je te werk gaat want het boek kun je lezen. En natuurlijk het zakelijke aspect ervan, een simpele apllicatie die heel ingwikkeld overkomt bij een klant kun je snel in elkaar bakken.

Het object georienteerde is nog wel wennen. In php werken we natuurlijk ook met objects maar ruby is wel een stapje hoger wat dat betreft :-)
Verder kwam ik een one-step installer inititief tegen dat ook heel makkelijk is. De volgende stap is wat grafische tools bouwen om de commandpromt te vervangen maar dat zal wel vanuit de community komen wanneer de interesse wat aantrekt.

Ik heb nog niet gekeken naar de complexere zaken (ingewikkelde tabel relaties, rechten systeem, uploads etc) maar heb er alle vertrouwen in dat dat goed komt.

Erg goed over nagedacht en zo zie je maar weer, eerst onderzoek en proberen voordat je het gaat becommentariëren.
Ik zeg er wel bij dat het filmpje niet de beste bron is om je mening op te baseren. Als je er echt mee werkt zie je pas hoe handig het is. Nu effe de verschillende editors proberen.

Jedit lukte niet omdat ik de benodigde plugins niet kon installeren vanauit de plugin manager.
Nu radrails proberen.
Wordt vervolgd...

Acties:
  • 0 Henk 'm!

  • Glival
  • Registratie: December 1999
  • Laatst online: 17-07 15:33
Verwijderd schreef op maandag 19 december 2005 @ 14:20:
Ik heb nog niet gekeken naar de complexere zaken (ingewikkelde tabel relaties, rechten systeem, uploads etc) maar heb er alle vertrouwen in dat dat goed komt.
Gisteren heb ik even met users, roles en permissions gespeeld, er is al wel wat voor (verschillende, maar deze is volgens mij het nieuwst en best uitgewerkt):
http://wiki.rubyonrails.c...s/LoginGeneratorACLSystem

Over relaties, in het rechten-systeem krijg je ook te maken met has_and_belongs_to_many (n-m relatie tussen roles en permissions bijvoorbeeld), een voorbeeld waarin het editten is uitgewerkt met checkboxes:
http://wiki.rubyonrails.com/rails/pages/CheckboxHABTM
Rails zoekt het allemaal netjes uit als je een tabel "roles", een tabel "permissions" en een koppeltabel "roles_permissions" met een role_id en permission_id hebt :)

Ik vind het zelf ook veelbelovend :)
In ieder geval leuk om eens uit te zoeken.

Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Damn... dat filmpje is wel inspirerend!!

Ik heb zojuist even een PHP script geschreven wat die code generator uit het filmpje voor php ook doorvoert, maar dan aan de hand van een al bestaande database.

Het doet een describe van alle tables in een tabel, zet die om naar objecten die automatisch aan de hand van de primary keys hun relaties vinden, en genereert daar automagisch m'n classes van 8-)
Nu nog even een lap code schrijven die de plugins met add/edit/delete/list/delete/connect/display functies erin genereert, en dan hoef ik alleen nog maar mn database netjes te ontwerpen, script draaien, en klaar is je raamwerk _O_ Scheelt een berg werk zeg :D

edit:

demo output tot zover:
http://home.schizofreend.nl/Analyzer.htm

[ Voor 9% gewijzigd door SchizoDuckie op 20-12-2005 00:17 ]

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
SchizoDuckie schreef op maandag 19 december 2005 @ 23:55:
Damn... dat filmpje is wel inspirerend!!

Ik heb zojuist even een PHP script geschreven wat die code generator uit het filmpje voor php ook doorvoert, maar dan aan de hand van een al bestaande database.

Het doet een describe van alle tables in een tabel, zet die om naar objecten die automatisch aan de hand van de primary keys hun relaties vinden, en genereert daar automagisch m'n classes van 8-)
Nu nog even een lap code schrijven die de plugins met add/edit/delete/list/delete/connect/display functies erin genereert, en dan hoef ik alleen nog maar mn database netjes te ontwerpen, script draaien, en klaar is je raamwerk _O_ Scheelt een berg werk zeg :D

edit:

demo output tot zover:
http://home.schizofreend.nl/Analyzer.htm
Dan nog 'even' een O/R mapper, classes met mixins (aka multiple inheritance maar dan nog een beetje anders), zowiezo een fatsoenlijke OO ondersteuning, en je had even goed direct in Ruby kunnen gaan programmeren! ;)

Verbouwing


Acties:
  • 0 Henk 'm!

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

En als je per se in PHP wil blijven programmeren (:X) gewoon een van de vele RoR-klonen gebruiken die er zijn voor PHP.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Mithrandir schreef op dinsdag 20 december 2005 @ 07:33:
[...]
Dan nog 'even' een O/R mapper, classes met mixins (aka multiple inheritance maar dan nog een beetje anders), zowiezo een fatsoenlijke OO ondersteuning, en je had even goed direct in Ruby kunnen gaan programmeren! ;)
Zullen we niet php of verschillende andere talen gaan afkraken?
Ik werk in PHP5 trouwens, daar is fatsoenlijke OO ondersteuning, plus ik werk al jaren in PHP, dus ik heb een code library opgeboud zoals veel andere programmeurs, inclusief een O/R mapper.
kenneth schreef op dinsdag 20 december 2005 @ 08:10:
En als je per se in PHP wil blijven programmeren (:X) gewoon een van de vele RoR-klonen gebruiken die er zijn voor PHP.
Tuurlijk. Je bouwt in de loop der jaren een compleet framework op van tig classes met database abstractie, etc, en dan begin je met een alpha framework kloon vanaf sourceforge.

No thanks :P

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

Verwijderd

Probeer het evengoed eens. Tis echt heel handig en gebruiksersvriendelijk.
zoals ik al eerder zei: filmpjes zijn maar filmpjes.

Klonen van frameworks zijn inderdaad geen goed idee, naam klonen ook niet ;-)

[ Voor 25% gewijzigd door Verwijderd op 20-12-2005 15:42 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Verwijderd schreef op dinsdag 20 december 2005 @ 15:23:
Probeer het evengoed eens. Tis echt heel handig en gebruiksersvriendelijk.
zoals ik al eerder zei: filmpjes zijn maar filmpjes
Leuk dat RoR, zeker voor kleine projectjes als nieuws sites en fora maar ik zal er niet mijn business aan toe vertrouwen.
1 omdat het zich bij lange na niet bewezen heeft
2 omdat het technisch veel te veel beperkingen heeft (ease of use comes with a price)

RoR is dus leuk om je een beetje te verbreden, niets meer dan dat.

Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Verwijderd schreef op dinsdag 20 december 2005 @ 15:47:
[...]
Leuk dat RoR, zeker voor kleine projectjes als nieuws sites en fora maar ik zal er niet mijn business aan toe vertrouwen.
1 omdat het zich bij lange na niet bewezen heeft
2 omdat het technisch veel te veel beperkingen heeft (ease of use comes with a price)

RoR is dus leuk om je een beetje te verbreden, niets meer dan dat.
Inderdaad. En kent iemand een nederlandse host waar Ruby door een webserver geparsed wordt? en daar ook support op levert?

[ Voor 3% gewijzigd door SchizoDuckie op 20-12-2005 16:03 . Reden: sex met komma's ]

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Rubyscript :? 8)7

En met "ease of use comes with a price" ben ik het niet eens. Dat is inderdaad wel vaak waar, maar evenzo is waar: het eenvoudige is simpel, het ingewikkelde is mogelijk.
Wat dat betreft is de beeldvorming een beetje krom. Klik, klik, klaar. Maar niemand houdt je tegen een complexe site in RoR te bouwen. Net zoals dat met Python en Perl gebeurt. En dat zal vast ook niet meer zo simpel zijn als het standaardwerk, maar als je het standaardwerk minimaliseert, scheelt dat in ieder geval een hoop werk.

Ik wil RoR vooral gebruiken voor prototyping, en daar is het natuurlijk ideaal voor.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
SchizoDuckie schreef op dinsdag 20 december 2005 @ 08:15:
[...]


Zullen we niet php of verschillende andere talen gaan afkraken?
Ik werk in PHP5 trouwens, daar is fatsoenlijke OO ondersteuning, plus ik werk al jaren in PHP, dus ik heb een code library opgeboud zoals veel andere programmeurs, inclusief een O/R mapper.
Ik wil php helemaal niet afkraken. Heb er zelf ook tijden in geprogrammeerd en meer dan de helft van mijn ontwikkeltijd besteed aan het maken van m'n tools. Dat die 'gratis' bij RoR zitten is gewoon een argument voor RoR, niet tégen php.
Tuurlijk. Je bouwt in de loop der jaren een compleet framework op van tig classes met database abstractie, etc, en dan begin je met een alpha framework kloon vanaf sourceforge.

No thanks :P
Tsja, iedereen moet daarin zijn eigen afweging maken. Ik vind het zeker niet vervelend om met RoR te werken en mijn oude classes 'weg te doen'.

Feit blijft dat de OOP ondersteuning van PHP niet geweldig is. Geen multiple inheritance of iets dat daar in de buurt komt is bijvoorbeeld erg jammer.

[ Voor 9% gewijzigd door Mithrandir op 20-12-2005 16:03 ]

Verbouwing


Acties:
  • 0 Henk 'm!

Verwijderd

Distributed transactions anyone?

Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
Tsja, voor DT wil je toch echt wel dat je database alle ACID properties heeft. MySQL (de meest gebruikte web-database) heeft die überhaupt niet, dus wat is je punt :?

Overigens is 't bijna altijd overbodig voor webapplicaties. En de keren dat je 't wel nodig hebt is inderdaad RoR vast geen goed idee, maar PHP zeker ook niet.

[toevoeging]
Verwijderd schreef op dinsdag 20 december 2005 @ 15:47:
[...]
Leuk dat RoR, zeker voor kleine projectjes als nieuws sites en fora maar ik zal er niet mijn business aan toe vertrouwen.
1 omdat het zich bij lange na niet bewezen heeft
2 omdat het technisch veel te veel beperkingen heeft (ease of use comes with a price)

RoR is dus leuk om je een beetje te verbreden, niets meer dan dat.
1. Tsja, ruby heeft zich niet bewezen, dat is waar. Voor unit tests zijn echter wel uitgebreide mogelijkheden, dus je eigen software goed testen kan. Schaalbaarheid e.d. bewijzen kan inderdaad nog even duren.
2. Ease of use komt in het geval van Ruby niet met een prijs. Iets wat makkelijk is kost bijna geen tijd, maar iets dat moeilijk is kan nog steeds.

[ Voor 55% gewijzigd door Mithrandir op 20-12-2005 16:26 ]

Verbouwing


Acties:
  • 0 Henk 'm!

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Verwijderd schreef op dinsdag 20 december 2005 @ 15:47:
2 omdat het technisch veel te veel beperkingen heeft (ease of use comes with a price)
Heb je daar een onderbouwing voor? Denk je dat het technische beperkingen heeft op ben je ze zelf tegengekomen? Dan ben ik erg benieuwd welke beperkingen dat zijn.

Acties:
  • 0 Henk 'm!

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Mithrandir schreef op dinsdag 20 december 2005 @ 16:21:
1. Tsja, ruby heeft zich niet bewezen, dat is waar.
Is dat zo? In Japan is Ruby populairder dan Python, om maar eens niet de minste scripttaal te noemen.
2. Ease of use komt in het geval van Ruby niet met een prijs. Iets wat makkelijk is kost bijna geen tijd, maar iets dat moeilijk is kan nog steeds.
GMTA ;)

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Acties:
  • 0 Henk 'm!

Verwijderd

Mithrandir schreef op dinsdag 20 december 2005 @ 16:21:
Tsja, voor DT wil je toch echt wel dat je database alle ACID properties heeft. MySQL (de meest gebruikte web-database) heeft die überhaupt niet, dus wat is je punt :?
Oftewel RoR richt zich niet op de serieuze webapplicatie markt. Dus daar vertrouw ik me business niet aan toe. Dat commentaar geld overigens ook voor MySQL.
Mithrandir schreef op dinsdag 20 december 2005 @ 16:21:
Overigens is 't bijna altijd overbodig voor webapplicaties. En de keren dat je 't wel nodig hebt is inderdaad RoR vast geen goed idee, maar PHP zeker ook niet.
Nee inderdaad, PHP zeker niet.
Mithrandir schreef op dinsdag 20 december 2005 @ 16:21:
1. Tsja, ruby heeft zich niet bewezen, dat is waar. Voor unit tests zijn echter wel uitgebreide mogelijkheden, dus je eigen software goed testen kan. Schaalbaarheid e.d. bewijzen kan inderdaad nog even duren.
2. Ease of use komt in het geval van Ruby niet met een prijs. Iets wat makkelijk is kost bijna geen tijd, maar iets dat moeilijk is kan nog steeds.
Nogmaals, distributed transactions kan niet.

Als het om ontwikkel tijd gaat wint overigens dat Oracle JSF spul het vast wel. Maar het probleem met (maatwerk) webapplicaties bijna nooit de ontwikkel tijd die nodig is voor het standaard werk maar de ontwikkeltijd die nodig is voor speciale wensen. De wensen die noch door RoR noch door het Oracle JSF spul worden ondersteund. En daarin heeft RoR gewoon nog een hele lange weg te gaan.

Acties:
  • 0 Henk 'm!

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Verwijderd schreef op dinsdag 20 december 2005 @ 16:41:
[...]
Oftewel RoR richt zich niet op de serieuze webapplicatie markt. Dus daar vertrouw ik me business niet aan toe. Dat commentaar geld overigens ook voor MySQL.
.
DT is toch meer database-afhankelijk? RoR is database-onafhankelijk, moet niet zo'n probleem worden dus. En wat zijn volgens jou de technische beperkingen die je hierboven noemde?

Acties:
  • 0 Henk 'm!

  • beany
  • Registratie: Juni 2001
  • Laatst online: 09:26

beany

Meeheheheheh

Ik vraag me ook af hoeveel lekken er nog in RoR zitten. Want daar is nog bar weinig over bekend. Ik zou dit dus niet willen gebruiken in een productie omgeving. Het is gewoon nog te nieuw. Pas over 1 a 2 jaar of zo, als het echt volwassen is geworden, dan ga ik er pas echt naar kijken.

Dagelijkse stats bronnen: https://x.com/GeneralStaffUA en https://www.facebook.com/GeneralStaff.ua


Acties:
  • 0 Henk 'm!

Verwijderd

chris schreef op dinsdag 20 december 2005 @ 16:53:
DT is toch meer database-afhankelijk? RoR is database-onafhankelijk, moet niet zo'n probleem worden dus. En wat zijn volgens jou de technische beperkingen die je hierboven noemde?
Nou dit is er 1 van. En er zijn er veel meer, ik heb het ooit is allemaal opgezocht omdat me het principe van DRY wel aansprak. Maar het was toen duidelijk een product wat in zijn kinderschoentjes stond.

En het parade paardje "DRY" wordt al jaren nagestreeft in de J2EE wereld. Alleen dan tegenwoordig beter onderbouwt door frameworks als springframework.

[ Voor 36% gewijzigd door Verwijderd op 20-12-2005 17:01 ]


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
.

[ Voor 149% gewijzigd door Mithrandir op 20-12-2005 17:06 ]

Verbouwing


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
Verwijderd schreef op dinsdag 20 december 2005 @ 16:59:
[...]

Nou dit is er 1 van. En er zijn er veel meer, ik heb het ooit is allemaal opgezocht omdat me het principe van DRY wel aansprak. Maar het was toen duidelijk een product wat in zijn kinderschoentjes stond.

En het parade paardje "DRY" wordt al jaren nagestreeft in de J2EE wereld. Alleen dan tegenwoordig beter onderbouwt door frameworks als springframework.
http://www.relevancellc.com/blogs/?p=92

Lees dit eerst eens? 't Is dus wel degelijk veel sneller. [qua ontwikkeltijd dus. dry.]

@beany:
Over lekken: alles is behoorlijk goed getest, dus ik vraag me af wat voor 'lekken' je bedoelt. SQL injection? Tsja, moet je zelf op letten maar als je van de standaardfuncties gebruik maakt heb je daar zeker geen last van.

[ Voor 7% gewijzigd door Mithrandir op 20-12-2005 17:19 ]

Verbouwing


Acties:
  • 0 Henk 'm!

  • beany
  • Registratie: Juni 2001
  • Laatst online: 09:26

beany

Meeheheheheh

Mithrandir schreef op dinsdag 20 december 2005 @ 17:06:
[...]


http://www.relevancellc.com/blogs/?p=92

Lees dit eerst eens? 't Is dus wel degelijk veel sneller.

Over lekken: alles is behoorlijk goed getest, dus ik vraag me af wat voor 'lekken' je bedoelt. SQL injection? Tsja, moet je zelf op letten maar als je van de standaardfuncties gebruik maakt heb je daar zeker geen last van.
omfg :X

Dagelijkse stats bronnen: https://x.com/GeneralStaffUA en https://www.facebook.com/GeneralStaff.ua


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
OMFGWTFROFL :X

?

[edit]
Tsja? Wat wil je nou zeggen eigenlijk? Alle input wordt voordat 't de database ingaat ge-escaped (iig, voor de functies die standaard in 't framework zitten) en voor de rest heb je de zelfde vrijheid (en dus 'mogelijke gevaren') als in veel andere frameworks.

[ Voor 52% gewijzigd door Mithrandir op 20-12-2005 17:18 ]

Verbouwing


Acties:
  • 0 Henk 'm!

Verwijderd

Tsja als jij zo conclusies trekt dan is inderdaad RoR helemaal het einde :)

Gelukkig trek ik zo geen conclusies. Een onderzoek zonder statistieken is geen onderzoek. Er wordt met getallen gesmeten die nergens onderbouwt worden. Het is dus een nietszeggende blog.

De meeste argumenten zijn ook zo te verwerpen waar de snelheid winst gehaald wordt, daarmee doelend op bijvoorbeeld 'compactere code'. Daar hebben we toch code generators voor uitgevonden... en dan hebben we ook nog zoiets als een Hibernate mapping generator. De java wereld heeft het allemaal al...

Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
Verwijderd schreef op dinsdag 20 december 2005 @ 17:18:
[...]
Tsja als jij zo conclusies trekt dan is inderdaad RoR helemaal het einde :)

Gelukkig trek ik zo geen conclusies. Een onderzoek zonder statistieken is geen onderzoek. Er wordt met getallen gesmeten die nergens onderbouwt worden. Het is dus een nietszeggende blog.

De meeste argumenten zijn ook zo te verwerpen waar de snelheid winst gehaald wordt, daarmee doelend op bijvoorbeeld 'compactere code'. Daar hebben we toch code generators voor uitgevonden... en dan hebben we ook nog zoiets als een Hibernate mapping generator. De java wereld heeft het allemaal al...
Tsja. Als je 't blog goed gelezen had zul je zien dat ze eerst van een javaomgeving komen en oa spring & beans gebruiken.

Als je met posts gaat gooien als 'Distributed transactions anyone?' zonder onderbouwing moet je inderdaad vooral voor java blijven kiezen. Even log & stug. ;)

[ Voor 5% gewijzigd door Mithrandir op 20-12-2005 17:25 ]

Verbouwing


Acties:
  • 0 Henk 'm!

Verwijderd

Mithrandir schreef op dinsdag 20 december 2005 @ 17:25:
Tsja. Als je 't blog goed gelezen had zul je zien dat ze eerst van een javaomgeving komen en oa spring & beans gebruiken.
Ja en dan? Als er gestaan had "ze gebruiken spring, beans en kruidnagel", had je dat hier ook neergekalkt. Zijn het nu opeens de mensen die er alles vanaf weten omdat ze een term en een framework kunnen opsommen? Nee inderdaad dat zijn het niet. Het is en blijft een nietszeggende blog.
Mithrandir schreef op dinsdag 20 december 2005 @ 17:25:Als je met posts gaat gooien als 'Distributed transactions anyone?' zonder onderbouwing moet je inderdaad vooral voor java blijven kiezen.
Wat valt er aan te onderbouwen, het zit er nou eenmaal niet in. Dus op de vraag: "voldoet RoR voor een serieuze webapplicatie", kunnen we allemaal volmondig "nee" antwoorden. :)

Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

M.b.t. DT: nu weet ik niet veel (zegmaar weinig) van DT, maar naar wat ik ervan begrijp valt dit makkelijk in RoR in te passen. Het zít er misschien niet in, maar de database handler die je moet maken en wat extensies op AR lijken me toch wel mogelijk en voldoende om het in RoR in te passen? Maar ik kan er ook compleet naast zitten...

DM!


Acties:
  • 0 Henk 'm!

  • ludo
  • Registratie: Oktober 2000
  • Laatst online: 26-04-2024
Verwijderd schreef op dinsdag 20 december 2005 @ 17:38:
[...]
Wat valt er aan te onderbouwen, het zit er nou eenmaal niet in. Dus op de vraag: "voldoet RoR voor een serieuze webapplicatie", kunnen we allemaal volmondig "nee" antwoorden. :)
Dus een serieuze webapplicatie móet gebruikmaken van Distributed Transactions :? :z

Maar even serieus: heb je zelf ook een serieuze blik geworpen op Ruby? En Rails? Want als dat niet zo is kunnen we jouw opmerkingen natuurlijk net zo goed onderverdelen bij de nietszeggende berichten, net als volgens jou die blogpost. Met Java zijn hele serieuze webapplicaties te maken, maar met Ruby net zo goed. Evetuele specifieke eisen zullen er voor zorgen dat je dan wel het een, dan wel het ander kiest. Beide hebben bepaalde kwaliteiten die, wanner goed benut, zeer goede producten op kunnen leveren. Maar bij voorbaat roepen dat iets niet geschikt is voor 'serieuze' dingen vind ik niet erg professioneel.

Acties:
  • 0 Henk 'm!

Verwijderd

Die blogpost moet je als niet serieus beschouwen. Het is simpelweg cijfers gooien zonder onderbouwing; er staat geen enkel feit in. Ja ik heb serieus gekeken naar Rails. Ik heb al aangegeven dat ik Ruby zeer geschikt acht voor fora en news sites. Maar voor de bedrijfskritische applicaties niet aangezien de focus vanuit de ontwikkeling niet die kant op gaat. Verder heb ik niks bij voorbaat geroepen.

[ Voor 11% gewijzigd door Verwijderd op 20-12-2005 18:31 ]


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 09:38
Verwijderd schreef op dinsdag 20 december 2005 @ 18:31:
Die blogpost moet je als niet serieus beschouwen. Het is simpelweg cijfers gooien zonder onderbouwing; er staat geen enkel feit in. Ja ik heb serieus gekeken naar Rails. Ik heb al aangegeven dat ik Ruby zeer geschikt acht voor fora en news sites. Maar voor de bedrijfskritische applicaties niet aangezien de focus vanuit de ontwikkeling niet die kant op gaat. Verder heb ik niks bij voorbaat geroepen.
Tsja, daar sluit ik me wel bij aan, maar dan moet je niet met posts maken zonder onderbouwing. (die hierboven mbt DT) RoR is er helemaal niet voor gemaakt; waarom zou je dan in een forum tien keer vertellen dat het niets is omdat JIJ er niet mee kunt wat je wilt?

Verbouwing


Acties:
  • 0 Henk 'm!

Verwijderd

Kijken is heel anders dan proberen. Ik had in het begin ook sterke twijfels en begon van alles te roepen. Had wel een en ander bekeken en gelezen.
Maar nadat ik het geprobeerd had vond ik het veelbelovend.
RoR is dus leuk om je een beetje te verbreden, niets meer dan dat.
Dit is echt te kort door de bocht maar wel erg typerend. De meeste mensen zien een nieuw initiatief zo. Dat betekend dat mensen die wel wat vrijer van geest zijn en wat verder durven te kijken dan de vermoedens die ze in eerste instantie hebben een voorsprong op kunnen bouwen tov de concurrentie. :)

Maar serieus, ik heb een seminar bekeken van de bedenker. Hij heeft het zelfde framework ook in PhP gebouwd maar liep tegen te veel obstakels op. Dat zegt al wat.
Over java weet ik niets maar ik kan me niet zo goed voorstellen wat voor enorme moeilijke business applicaties je dan wilt bouwen. Wat is dus niet mogelijk in ruby? weet je me dat te vertellen?
Ik heb het dan niet over dingen die niet standaard zijn bijgeleverd...
Ben hier benieuwd naar omdat ik met een bedrijf bezig ben en we zijn serieus aan het bekijken of ruby en ruby on rails iets voor ons is.

Acties:
  • 0 Henk 'm!

Verwijderd

Mr Platvoet,
Ik had gehoopt dat je met een goede reply zou komen! Ik ben niet 100% pro en niet 100% contra dus alle gegronde meningen zijn welkom.

Verwijderd

Verwijderd schreef op dinsdag 20 december 2005 @ 19:00:Wat is dus niet mogelijk in ruby? weet je me dat te vertellen?
Ik heb het dan niet over dingen die niet standaard zijn bijgeleverd...
Jij vraagt me nu feitelijk de beperkingen te noemen zonder dat ik beperkingen mag noemen :?

Een ding wat zeker wel in het voordeel van Ruby pleit is het standaard gebruik van decorators. er wordt onderkent dat template engines zwaar achterhaalt zijn.

Verwijderd

Jij vraagt me nu feitelijk de beperkingen te noemen zonder dat ik beperkingen mag noemen
Ok de formulering is feitelijk gezien niet de gene die ik bedoelde ;)

Ik bedoel als jij het bv over Distributed Transactions hebt, is dat dan helemaal niet te bouwen met ruby?

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Given the will you can build anything in ruby :)

Alles zal kunnen, maar het moet er dan wel zijn, of het moet gemaakt worden, en door tijd en ervaring even stabiel, snel en goed worden als DT-support op andere platformen.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Verwijderd

True, alleen als je de DT architectuur van de andere platformen al kent, hoef je het alleen maar na te bouwen. Scheelt weer :-)

Moet wel zeggen dat de ruby syntax wel effe wennen is...

  • D4Skunk
  • Registratie: Juni 2003
  • Laatst online: 18-06 09:04

D4Skunk

Kind of Blue

Tof dat er nu toch al wat meer mensen zijn die ROR kennen. Toen ik het enkele maanden geleden in een post vermelde, bleek het nog relatief onbekend te zijn, en nu begint het -onder voorbehoud- toch al iets bekender te worden. De meesten willen natuurlijk - volledig terecht- geen voortrekker worden.

Ikzelf ben nu ernstig aan het overwegen om een CRM-project voor 1 van mijn klanten misschien toch maar in rails te gaan doen... Maar ik moet zeggen dat de twijfel er nog steeds is...

Wat betreft de aanvaarding : er moet altijd een generatie believers zijn die het pad effent voor de rest..
Vergelijk het met een early adopter in de marketing.

Sommige mensen zweren nu nog steeds bij COBOL, en in haar niche zal cobol misschien wel idd een prachtig product zijn, maar ik wil er voor de dood niet meer in werken...

Probeer non-believers niet te overtuigen, maar steek je energie in het creëren van iets constructief....

OMG, ik lijk net een of andere sjamaan als ik dit zo herlees, tijd op m'n mond te houden :p

Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 18:49
... maar je hebt wel helemaal gelijk. :)

Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

D4Skunk schreef op donderdag 22 december 2005 @ 23:30:
Ikzelf ben nu ernstig aan het overwegen om een CRM-project voor 1 van mijn klanten misschien toch maar in rails te gaan doen... Maar ik moet zeggen dat de twijfel er nog steeds is...
37signals schijnt overigens binnen een maand of 2 met een op het MKB gericht online CRM pakket te komen, in Rails natuurlijk :) .

DM!


Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 13-07 01:14
Ik denk dat het een kwestie van tijd is voordat Rails echt geaccepteerd word. Het is een erg jonge ontwikkelomgeving, zulk soort dingen hebben tijd nodig. PHP was ook niet een instant hit (volgens mij, ik heb er geen verstand van dus dat was een ongegronde zin :+ ), maar door mensen die zich er in verdiepten en er hele mooie producten van maakten is het een van de, danwel de grootste webscripting taal geworden.

Zo is het ook met Rails. Er is een groep mensen nodig die mooie producten maakt, die tutorials schrijven, die verbeteringen naar de ontwikkelaars sturen, voordat het een wijd geaccepteerd iets word.

En dan is het nog maar de vraag of het ook echt iets wijd geaccepteerd word natuurlijk :+.

Acties:
  • 0 Henk 'm!

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Ook negatieve aandacht is aandacht. Ik denk persoonlijk dat er heel veel mensen zijn die baat hebben bij RoR, daarom heb ik dit topic ook geopend. Ik ben ook blij dat er stevige discussie is tussen de bedenker en Bruce Eckel. Bruce is (naar mijn mening erg ongegrond) tegen Ruby, hij ziet het als een soort veredelde versie van Perl volgens mij. Het mooie is dat hij hiermee reacties uitlokt van echte Rubyists, die precies kunnen laten zien wat er nou zo mooi is aan Ruby (on Rails). En hij zorgt (ongewenst) voor nog veel meer aandacht voor Ruby.

Verder ben ik het helemaal eens met YopY hierboven. Over de vraag of het wijd geaccepteerd gaat worden: het idee is heel erg mooi, en er zijn veel mensen die het idee heel erg mooi vinden, en als het niet RoR wordt, dan wordt het iets wat er heel erg op lijkt. Het mooie van Rails is dat er echt heel veel jaren aan ervaring in zit, b.v. het gebruik van Design Patterns als MVC en een OR-mapper, dat zijn dingen die de auteur niet zelf heeft bedacht maar (imo) op een ontzettend mooie manier heeft opgelost.

Acties:
  • 0 Henk 'm!

  • Parcye
  • Registratie: Maart 2001
  • Laatst online: 24-08-2017

Parcye

Mr C

Eigenlijk is het precies wat iedereen die veel domme formulieren en afhandeling wil doen nodig heeft.

Sommige (oa ik) hebben hier inmiddels zelf een boel handige dingen voor gemaakt en dan kan ik me heel goed voorstellen dat je denkt 'voor mij is dit niet nodig'.

Het heeft voor simpele database applicaties zeker zo zijn voordelen maar niet genoeg voor mij om er aandacht aan te besteden.

"Als je het kan bedenken, kan het gemaakt worden" Parcye - 14 januari 2002


Acties:
  • 0 Henk 'm!

Verwijderd

Probeer non-believers niet te overtuigen, maar steek je energie in het creëren van iets constructief....
Sjamaan, je hebt gelijk. Volgende week hoop ik weer verder te kunnen met het testen van ror.
Hoop dat ik dan ook wat ingewikkeldere dingen kan gaan testen.

Acties:
  • 0 Henk 'm!

Verwijderd

Ik vind het maar prima dat mensen rails niet accepteren : ) meer markt voor mij ;)

Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 13-07 01:14
Heh, da's wel zo. De markt van bijvoorbeeld blog, forum en nieuwssoftware word door deze software min of meer bedreigd - met RoR kun je een vergelijkbaar product maken, maar veel sneller. Wat dat betekent is dat de software gemaakt in RoR goedkoper is, wat natuurlijk concurrentie is voor de gevestigde orde.

IIG, mijn boek is er nog niet :'(.

Acties:
  • 0 Henk 'm!

Verwijderd

RoR kun je een vergelijkbaar product maken, maar veel sneller
En vooral ook makkelijker een mooi ontwerp (visuele vormgeving) neer kunnen zetten.

Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Gisteren en vandaag bezig geweest met TurboGears, nu met Ruby ... Was dus aan het kijken naar dat koekboekje maar MySQL doet niet zo lief. :( Als ik naar 'recipe/new' ga krijg ik:
Mysql::Error: Lost connection to MySQL server during query: SHOW FIELDS FROM recipes
Heb nog niet kunnen vinden waarom dit is helaas... Op zich vind ik RoR namelijk best leuk er uit zien. :)

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

blizt: iirc: dan heb je de oude mysql-bindings waardoor het wachtwoord niet in hetzelfde formaat overkomt. Om te controleren even zonder wachtwoord proberen. En misschien even in het log kijken of daar verder nog wat staat. Anders misschien even kijken of je een topic kunt openen, dan wordt dit topic niet vervuild (kan je wel hier een linkje achterlaten) :) .

DM!


Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Heb een nieuwe user aangemaakt en daarbij het wachtwoord encrypted met PASSWORD() en daarna een keertje geprobeerd met OLD_PASSWORD()... In beide gevallen krijg ik de bovenstaande melding, probeer ik zonder password te connecten krijg ik gewoon 'n "access denied".

Nu ja, zal nog ff beetje proberen later vandaag en anders topic openen. Nu moet ik eigenlijk bezig zijn met andere dingen. ;)

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • DaCoTa
  • Registratie: April 2002
  • Laatst online: 04-07 23:41
Zijn er al mensen die RoR op commerciele basis gebruiken, als in, opdrachten aannemen van klanten en uitvoeren? Zo ja, wat zijn dan de ervaringen van dat proces, van ontwikkeling, klanttevredenheid, hosting?

Het bedrijf waar ik werk zit 100% in Java, maar zijn altijd wel geinteresseerd in nieuwe ontwikkeling en wat ik zo over RoR lees, is het wel de moeite waard om het een keer te proberen in een klein project.

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
DaCoTa schreef op vrijdag 30 december 2005 @ 13:06:
Zijn er al mensen die RoR op commerciele basis gebruiken, als in, opdrachten aannemen van klanten en uitvoeren? Zo ja, wat zijn dan de ervaringen van dat proces, van ontwikkeling, klanttevredenheid, hosting?

Het bedrijf waar ik werk zit 100% in Java, maar zijn altijd wel geinteresseerd in nieuwe ontwikkeling en wat ik zo over RoR lees, is het wel de moeite waard om het een keer te proberen in een klein project.
Ik heb RoR gebruikt voor een het opzetten van een CMS voor een klant. Doel was om een standalone applicatie te maken waarbij een Flash movie tegen een database praat. In eerste instantie dachten we aan een pure XML oplossing waarbij het zoeken via Flash zou gebeuren. Maar al snel bleek dat dat te veel gedoe ging worden door de vele relaties.

Daarna werd PHP/SQLite/Apache overwogen, maar dit viel ook af omdat de installatie van Apache wel erg veel overkill zou zijn.
Ik had al gekeken naar RoR (zo'n maand of 5 geleden ten tijde van rails 0.12/0.13) en was erg gecharmeerd van de applicatie. Via scaffold was een kale applicatie neergezet zodat de klant al meteen kun vullen en het ontwikkelen toch nog door kon gaan.

Het ontwikkelen ging vrij snel en ik ben maar weinig serieuze problemen tegengekomen, op 1 vervelende na. Een memory leak in development mode, dat in production mode zich niet terugkwam.

Afijn, klant blij want we konden snel het product opleveren. Een windows installer gemaakt die een gestripte Ruby 1.8 installatie + de Rails applicatie installeerde op de computers. Dit werkte zonder problemen:
- snelkoppeling op bureaublad start de Rail's webrick server.
- webrick script opent in een nieuwe thread de Flash applicatie die fullscreen draait.
- gehele applicatie wordt in het geheugen geladen (production mode) dus het loopt erg soepel.
- na afsluiten Flash wordt ook webrick gestopt en blijft er niks in het geheugen achter.

Hosting doe ik zelf op Apache2 via mod_fastcgid (Debian). Het enige nadeel kan zijn dat je veel Ruby processen krijgt op je server omdat, in tegenstelling tot PHP, mod_ruby niet bruikbaar is.
Eigelijk is het tot nu toe geen issue geweest en de RoR applicatie wordt straks uitgerold in 200 winkels :)

Onze klanten maakt het geen bal uit of we nu PHP/Ruby/Java gebruiken aangezien ze gewoon willen dat het goed werkt. Per case wordt gekeken welke middelen ingezet worden.

De onderhoudbaarheid van de code is nog steeds erg goed bij RoR omdat je vooral in het framework van RoR moet blijven en je niet zo maar moet freestylen.
Ook bijv. AJAX interactie is nog steeds erg handig en de API is goed gedocumenteerd en je kan natuurlijk altijd de implementatie van een method bekijken.

Standaard leesvoer blijft Programming Ruby: The Pragmatic Programmers' Guide, Second Edition en Agile Web Development with Rails : A Pragmatic Guide van dezelfde auteur (Dave Thomas) en te koop via o.a. Amazon.

Beide boeken hebben mij veel meer inzicht gegeven in Rails en Ruby.

Het valt me tegen dat er in dit topic zo weinig gepost is, zijn mensen onbekend met Ruby of zijn het allemaal die-hards Java programmeurs?

Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

DaCoTa schreef op vrijdag 30 december 2005 @ 13:06:
Zijn er al mensen die RoR op commerciele basis gebruiken, als in, opdrachten aannemen van klanten en uitvoeren? Zo ja, wat zijn dan de ervaringen van dat proces, van ontwikkeling, klanttevredenheid, hosting?
Ja, goed, goed, goed, redelijk :P . Wij hebben het gebruikt* voor enkele kleine websites met enige interactiviteit (nieuws posten, pagina's toevoegen en bewerken, reacties plaatsen, dat soort meuk), en enkele intranetsites met heel basaal gesproken hetzelfde werk, en wat projectmanagement gedoe :) .

Zelf ben ik helemaal dol op de Agile manier van ontwikkelen: je gaat naar de klant toe, je maakt een eerste opzet in een kwartiertje / halfuurtje met pagina's en nieuws. Laat het zien, past wat aan, halfuur later heb je een basaal inlog en edit systeem. Ze blijken ook een reactiemogelijkheid te willen zien. Kwartiertje later bestaat ook dat nog. Je gaat weer naar huis, designers gaan aan het werken, je maakt het systeem verder in orde. Designers gaan een keertje naar de klant toe. Later kom je zelf nog eens terug om het proces af te ronden. Geweldig :) . Hosten gebeurt o.a. bij Dreamhost, werkt redelijk, weinig problemen, enigzins langzaam als de FastCGI handler moet opstarten, maar verder ok.

* Deels nog in ontwikkeling. Ik ben niet op elk systeem even trots, maar al doende leert men.

DM!


Acties:
  • 0 Henk 'm!

Verwijderd

DaCoTa schreef op vrijdag 30 december 2005 @ 13:06:
Zijn er al mensen die RoR op commerciele basis gebruiken, als in, opdrachten aannemen van klanten en uitvoeren? Zo ja, wat zijn dan de ervaringen van dat proces, van ontwikkeling, klanttevredenheid, hosting?

Het bedrijf waar ik werk zit 100% in Java, maar zijn altijd wel geinteresseerd in nieuwe ontwikkeling en wat ik zo over RoR lees, is het wel de moeite waard om het een keer te proberen in een klein project.
Gebruik het zelf voor momenteel een groot project. Tijdens de ontwikkeling van dat project zijn er al 2 patches righting the core gestroomd (hoewel eentje daarvan werd herschrijven :P). En een aantal leuke plugins eruit gestroomd.

Gebruik het zelf niet helemaal zoals JHS maar bij ons is het ook een redelijk complex systeem wat neergezet moet worden. Ik denk dat ik over een maand wel een stuk beter in rails zit om een goed oordeel erover te vellen.

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Ik heb net die video bekeken over Migrations. Het werkt een beetje zoals ieder version control systeem alleen het coole hier is eigelijk dat je de table definities bewerkt in Ruby en dat je dus ook Ruby commando's kan uitvoeren tijdens de migratie. Best wel makkelijk omdat vaak bij revisies ook database aanpassingen komen en je de huidige data toch wil bewaren.

Acties:
  • 0 Henk 'm!

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
smesjz schreef op vrijdag 30 december 2005 @ 20:24:
Ik heb net die video bekeken over Migrations. Het werkt een beetje zoals ieder version control systeem alleen het coole hier is eigelijk dat je de table definities bewerkt in Ruby en dat je dus ook Ruby commando's kan uitvoeren tijdens de migratie. Best wel makkelijk omdat vaak bij revisies ook database aanpassingen komen en je de huidige data toch wil bewaren.
Ja, het is echt cool bedacht. Zoals bij bijna alles in RoR is het niet zwaar vernieuwend, maar wel heel erg mooi uitgewerkt. Ook is het mooi dat je ook database-onafhankelijk bent geworden, doordat je je tables in ruby definieert kan je later zonder enige moeite switchen van MySQL naar pg of naar sqlite! Vet relaxed :)

Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 13-07 01:14
Het valt me tegen dat er in dit topic zo weinig gepost is, zijn mensen onbekend met Ruby of zijn het allemaal die-hards Java programmeurs?
Nee, mijn RoR-boek is laat :(. Bol.com zegt "Tot onze spijt kunnen wij dit artikel niet binnen de afgesproken tijd aan u leveren. Wij doen ons uiterste best om het zo
spoedig mogelijk bij u te bezorgen. Onze excuses voor het ongemak en bij voorbaat dank voor uw geduld."

:(

Naja, ben toch nog bezig met een PHP project(je), in principe gewoon een eenvoudige CMS, basaal database opzoek / toevoeg / bewerk / verwijder werk... Precies datgene waar RoR goed voor is :+.

Acties:
  • 0 Henk 'm!

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
YopY schreef op zaterdag 31 december 2005 @ 11:15:
Naja, ben toch nog bezig met een PHP project(je), in principe gewoon een eenvoudige CMS, basaal database opzoek / toevoeg / bewerk / verwijder werk... Precies datgene waar RoR goed voor is :+.
Wees blij. Ik doe ook nog php-werk, maar dat is echt niet leuk meer als je ook maar weet dat RoR bestaat...

Acties:
  • 0 Henk 'm!

Verwijderd

chris schreef op zaterdag 31 december 2005 @ 11:19:
[...]

Wees blij. Ik doe ook nog php-werk, maar dat is echt niet leuk meer als je ook maar weet dat RoR bestaat...
jah, als je met java bezig bent valt het nog wel mee... overgens er zitten ook nadelen aan RoR : ) mensen zijn zo positief dat ze de nadelen maar voor lief nemen zonder even onderzoek te doen

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
YopY schreef op zaterdag 31 december 2005 @ 11:15:
[...]


Nee, mijn RoR-boek is laat :(. Bol.com zegt "Tot onze spijt kunnen wij dit artikel niet binnen de afgesproken tijd aan u leveren. Wij doen ons uiterste best om het zo
spoedig mogelijk bij u te bezorgen. Onze excuses voor het ongemak en bij voorbaat dank voor uw geduld."

:(

Naja, ben toch nog bezig met een PHP project(je), in principe gewoon een eenvoudige CMS, basaal database opzoek / toevoeg / bewerk / verwijder werk... Precies datgene waar RoR goed voor is :+.
Gisteren nog voor iemand RoR + Programming Ruby besteld bij Amazon, vanochtend mailtje gekregen dat boeken geshipped worden. Zo kan het ook. Alleen een estimated arrival date van 2 februari 2006, maar mijn ervaring is dat het niet zo lang duurt.

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Verwijderd schreef op zaterdag 31 december 2005 @ 12:25:
[...]
jah, als je met java bezig bent valt het nog wel mee... overgens er zitten ook nadelen aan RoR : ) mensen zijn zo positief dat ze de nadelen maar voor lief nemen zonder even onderzoek te doen
Voor veel nadelen is ook wel iets te vinden, verder kan ik je aanraden om ook edge rails te gebruiken, het laatste snapshot uit subversion. Ruby zelf lijkt me niet echt snel te ontwikkelen, ik heb 1.8.2 als eerste gebruikt en nu is 1.8.4 de huidige stable.

Niet dat daar is mis mee is, ik vind Ruby als taal nog steeds krachtiger dan PHP (extensies even buiten beschouwing gelaten).

Op welke RoR nadelen doel je dan? Dat je console toegang nodig hebt om 'rails' of 'rake' te gebruiken lijkt me logisch...

Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 13-07 01:14
Wees blij. Ik doe ook nog php-werk, maar dat is echt niet leuk meer als je ook maar weet dat RoR bestaat...
Ik weet het :(. Ik ben er al mee bezig sinds een week voor de kerstvakantie (uurtje per dag, misschien minder), maar tot nu toe alleen nog maar bezig geweest met het achtergrondverhaal :'(. Maar dat is hopelijk snel klaar, kan ik aan de layout enzo beginnen.

Acties:
  • 0 Henk 'm!

  • GX
  • Registratie: Augustus 2000
  • Laatst online: 14-05 09:40

GX

Nee.

Zou iemand die er al wat dieper in zit even de moeite willen doen om de nadelen en voordelen op te sommen tegenover bijvoorbeeld PHP en C#.Net (uit ASP) zodat er een goed evenwichtig beeld van ontstaat? Want als ik dit topic doorskim zie ik alleen maar 'jeuh'-reacties en ik zoek juist een helder beeld.

Zelf ontwikkel ik nu alleen maar in C++ en PHP voor m'n werk en een migratie naar andere talen zit er voorlopig nog niet in op de PHP -> J2EE na. Desondanks ben ik wel benieuwd wat RoR mij nou zou kunnen bieden voor complexe* webapplicaties.

* Dus geen weblog of nieuwssite, maar enterprise-level logistieke dossiervolgapplicaties

[ Voor 4% gewijzigd door GX op 31-12-2005 13:27 ]


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
GX schreef op zaterdag 31 december 2005 @ 13:27:
Zou iemand die er al wat dieper in zit even de moeite willen doen om de nadelen en voordelen op te sommen tegenover bijvoorbeeld PHP en C#.Net (uit ASP) zodat er een goed evenwichtig beeld van ontstaat? Want als ik dit topic doorskim zie ik alleen maar 'jeuh'-reacties en ik zoek juist een helder beeld.

Zelf ontwikkel ik nu alleen maar in C++ en PHP voor m'n werk en een migratie naar andere talen zit er voorlopig nog niet in op de PHP -> J2EE na. Desondanks ben ik wel benieuwd wat RoR mij nou zou kunnen bieden voor complexe* webapplicaties.

* Dus geen weblog of nieuwssite, maar enterprise-level logistieke dossiervolgapplicaties
Er zijn genoeg bronnen buiten dit topic en de RoR website die je kan raadplegen. Bruce Eckel (java dude en schrijver van Java boeken) heeft ook wat commentaar op Ruby waar David HH (auteur RoR) op reageert in zijn blog:
http://www.loudthinking.com/arc/000551.html

Ik weet niet wat RoR je kan bieden, het bracht mij weer plezier terug in applicaties ontwikkelen. Met weinig regels code toch technische mooie programma's maken. Of het geschikt is voor jouw enterprise level applicaties weet ik niet, maar wat houd je tegen om zelf iets te proberen? Dat lijkt mij de enige manier om inzicht te krijgen in zowel Ruby als Rails.

Acties:
  • 0 Henk 'm!

  • GX
  • Registratie: Augustus 2000
  • Laatst online: 14-05 09:40

GX

Nee.

smesjz schreef op zaterdag 31 december 2005 @ 14:24:
wat houd je tegen om zelf iets te proberen?
Tijd, geld, support en platform.

Desondanks zal ik even de link bekijken. Dankje

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
GX schreef op zaterdag 31 december 2005 @ 14:31:
[...]

Tijd, geld, support en platform.

Desondanks zal ik even de link bekijken. Dankje
Tijd, geld, support en platform lijken me alleen issues als je Rails professioneel gaat inzetten en staan natuurlijk het proberen van Rails of je eigen workstation thuis niet in de weg.

Die videocasts van David HH zijn erg interessant als je met Rails wil beginnen.

RoR is community driven dus veel support vind je al op de Rails wiki + IRC kanaal. Wat bedoel je precies met platform? I.t.t. java is er voor Rails geen applicatie-server. Buiten dat, Rails draait op Windows, Mac, Linux en kan met iedere gangbare dbase babbelen.

Acties:
  • 0 Henk 'm!

  • GX
  • Registratie: Augustus 2000
  • Laatst online: 14-05 09:40

GX

Nee.

smesjz schreef op zaterdag 31 december 2005 @ 15:18:
[...]


Tijd, geld, support en platform lijken me alleen issues als je Rails professioneel gaat inzetten en staan natuurlijk het proberen van Rails of je eigen workstation thuis niet in de weg.

Die videocasts van David HH zijn erg interessant als je met Rails wil beginnen.

RoR is community driven dus veel support vind je al op de Rails wiki + IRC kanaal. Wat bedoel je precies met platform? I.t.t. java is er voor Rails geen applicatie-server. Buiten dat, Rails draait op Windows, Mac, Linux en kan met iedere gangbare dbase babbelen.
Naast m'n werk besteed ik de laatste tijd liever niet te veel tijd aan ontwikkelen, omdat het anders m'n hele leven opslokt ;). Ik krijg op m'n werk wel de vrijheid nieuwe technieken te proberen en aan te leren mits ze het waard zijn; daar moet ik dus de voordelen en nadelen op een rijtje hebben. Maar de platformen welke ik gebruik zijn de platformen welke we bij de klant geinstalleerd hebben, dus: Linux, AIX en HP-UX en in een enkel geval windows met cygwin, daarnaast gebruiken we een eigen ontwikkelde database welke aanspreekbaar is via ODBC en weer bij enkele gevallen een Oracle servertje. Al onze software moet dus redelijk portable zijn.

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
GX schreef op zaterdag 31 december 2005 @ 15:27:
[...]

Naast m'n werk besteed ik de laatste tijd liever niet te veel tijd aan ontwikkelen, omdat het anders m'n hele leven opslokt ;). Ik krijg op m'n werk wel de vrijheid nieuwe technieken te proberen en aan te leren mits ze het waard zijn; daar moet ik dus de voordelen en nadelen op een rijtje hebben. Maar de platformen welke ik gebruik zijn de platformen welke we bij de klant geinstalleerd hebben, dus: Linux, AIX en HP-UX en in een enkel geval windows met cygwin, daarnaast gebruiken we een eigen ontwikkelde database welke aanspreekbaar is via ODBC en weer bij enkele gevallen een Oracle servertje. Al onze software moet dus redelijk portable zijn.
Nou ja, volgens mij draait Ruby op ieder platform, het is ontwikkelt op Linux dus werkt het zeker goed op. Alles omklussen naar RoR is gewoon niet slim, lekker laten draaien zo lang het werkt.

Ik zou eerst zorgen dat je Ruby als taal snapt, voordat je uberhaupt naar Rails kijkt. Een vergelijking tussen PHP/C++ en Rails gaat natuurlijk mank, het laatste is immers een framework.

Je kan prima een Rails applicatie schrijven zonder 1 regel SQL code (inclusief aanmaken tabellen), dus qua portability zit het wel goed.

Op de Rails wiki e.d. zijn genoeg voorbeelden te zien, dus zolang de taal niet zelf het geprobeerd kan je ook geen voor- en nadelen afwegen lijkt me. Toch?

Acties:
  • 0 Henk 'm!

  • Copyman
  • Registratie: Januari 2001
  • Laatst online: 14-07 10:39

Copyman

Dode muis

Binnenkort ga ik een online systeem bouwen wat waarschijnlijk op PHP gaat draaien, maar sinds de opmars van Ruby, zit ik er aan te denken om het hier op te baseren. Het systeem bestaat grotendeels uit interactie tussen PHP en MySQL, inserten, selecten, deleten, etc.

Mocht ik voor Ruby kiezen, heeft dit dan vele voordelen ten opzichte van PHP?

Zeer belangrijke informatie: Inventaris


Acties:
  • 0 Henk 'm!

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Het is natuurlijk erg lastig om met beperkte informatie aan te geven voor welke taal je moet kiezen, maar ik vind als taal Ruby vele malen volwassener en doordachter dan PHP.
Als platform moet je zelf kijken of Rails, ActiveRecord en overige add-ons genoeg bieden voor wat jij wilt.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Acties:
  • 0 Henk 'm!

Verwijderd

smesjz schreef op zaterdag 31 december 2005 @ 12:39:
[...]


Voor veel nadelen is ook wel iets te vinden, verder kan ik je aanraden om ook edge rails te gebruiken, het laatste snapshot uit subversion. Ruby zelf lijkt me niet echt snel te ontwikkelen, ik heb 1.8.2 als eerste gebruikt en nu is 1.8.4 de huidige stable.

Niet dat daar is mis mee is, ik vind Ruby als taal nog steeds krachtiger dan PHP (extensies even buiten beschouwing gelaten).

Op welke RoR nadelen doel je dan? Dat je console toegang nodig hebt om 'rails' of 'rake' te gebruiken lijkt me logisch...
RoR heeft een aantal princiepes, en een van die princiepes van het core team zijn dat ze een beetje tegen components en krachtige plugins zijn. Dat maakt het soms moeilijk om bepaalde 'complexe' stukken code om te zetten om components.

Daarnaast zijn er nog zaken niet helemaal super gedocumenteerd (zelfs neit in het ror boek). Dat zorgt voor velen regels code lezen als er iets mis gaat : ). Maja, verder gebruik ik zelf al edgerails (eigenlijk al na 10 dagen met rails te werken).

Nu probeer ik zelf wel het een en ander te pushen via de core list, want op de rails channel zijn die core dev's zo snel bereikbaar...

Acties:
  • 0 Henk 'm!

  • alienfruit
  • Registratie: Maart 2003
  • Laatst online: 14:32

alienfruit

the alien you never expected

Programmeer ik toch liever in Chrome (mono ready) dan in Ruby sneller, makkelijker en cleanere syntax ;)

[ Voor 11% gewijzigd door alienfruit op 01-01-2006 08:34 ]


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Verwijderd schreef op zaterdag 31 december 2005 @ 23:02:
[...]
RoR heeft een aantal princiepes, en een van die princiepes van het core team zijn dat ze een beetje tegen components en krachtige plugins zijn. Dat maakt het soms moeilijk om bepaalde 'complexe' stukken code om te zetten om components.

Daarnaast zijn er nog zaken niet helemaal super gedocumenteerd (zelfs neit in het ror boek). Dat zorgt voor velen regels code lezen als er iets mis gaat : ). Maja, verder gebruik ik zelf al edgerails (eigenlijk al na 10 dagen met rails te werken).
Tegen components en krachtige plugins zijn? Kan je dit toelichten?
Nu probeer ik zelf wel het een en ander te pushen via de core list, want op de rails channel zijn die core dev's zo snel bereikbaar...
Op het rails kanaal zitten vooral veel end-users, David HH en andere core-developers zitten daar wat minder. Maar de list blijft toch altijd het centrale punt om development te bespreken.

Verder zou ik het wel een aanvulling vinden als er iets als gettext wordt gebruikt voor localization van berichten. Ik weet dat je modules gewoon kan overriden in je eigen rails directory, maar echt handig is niet bij het maken van vertalingen. Nu wordt er bijv. dit gebruikt:

http://wiki.rubyonrails.o...tePluginToModifyRailsCore

Maar alles blijft standaard in het Engels.

Acties:
  • 0 Henk 'm!

  • flowerp
  • Registratie: September 2003
  • Laatst online: 20-05 21:31
Interesante thread dit.

Wat me opvalt is dat nog niemand (of ik heb niet goed gelezen ;) ) een van de de voordelen van RoR hebben genoemd (tov Java/.Net): instant deployment.

Nu is het wel zo dat voor een productie omgeving je dit eigenlijk niet wilt, maar voor developpen is het gewoon heerlijk. Ik werk zelf veel in de business/logic layer van een Java EE web applicatie die draait op Tomcat. Voor elke method of class die ik ergens toevoeg -moet- ik de AS herstarten om te testen. In debug-mode is dat op een XP 2000+ workstation met 1GB RAM toch al snel een dikke 20 seconden wachten. (voornamelijk hibernate & jsf vertragen de opstart tijd).

JSP pagina's deployen wel instant, ook als je daar tonnen code op hebt staan. In Java heb je dan soms de ietwat merkwaardige situatie dat sommige java 'programmeurs' de slechtste eigenschap van PHP gaan overnemen (code op pagina's) alleen om het deployment argument.

Ruby laat hier zien dat het WEL kan, zonder viese PHP truukjes te hoeven gebruiken. Het vreemde is wel dat Java opzich hier wel is op voorbereid. De VM heeft vele interfaces voor het hot-deployen van classes. In de praktijk zijn deze helaas nutteloos want ze gooien bijna allemaal "not implemented" exceptions :(
Verwijderd schreef op dinsdag 29 december 2005 @ 17:18:
De meeste argumenten zijn ook zo te verwerpen waar de snelheid winst gehaald wordt, daarmee doelend op bijvoorbeeld 'compactere code'. Daar hebben we toch code generators voor uitgevonden... en dan hebben we ook nog zoiets als een Hibernate mapping generator. De java wereld heeft het allemaal al...
Inderdaad. Op wat kleinere dingetjes na (zoals de deployment), overtreed Ruby toch wel z'n eigen DRY regel. Dingen zoals MVC, OR mapping en andere zaken bestaan gewoon al in Java. Waarom alles overnieuw uitvinden als Java het al heeft? Wie is nou zichzelf aan het repeaten?

Had het development team van Ruby mischien niet beter een JSR kunnen leiden die de hot-deployment van classen in Java regelt?

De PHP wereld zie je toch ook wel een beetje die kant opgaan. Van een ranzig script-taaltje wat iedereen zo roemde (want simpel, en klein), zijn ze steeds meer dingen gaan toevoegen die Java ook heeft. Classen (kun je eigenlijk niet 'even' toevoegen, maar goed de m*ll*ten van PHP deden het toch :X ), universele DB access, (soort van) strong typing, toolsupport (IDE's), straks ook volwassen MVC frameworks etc etc.

Al die alternatieve talen gaan gewoon dezelfde ontwikkeling als Java al heeft gehad doormaken. Dan heb je over 10 jaar PHP dat op 2 druppels water lijkt op het Java van nu. Alle prutsers vinden het dan super (want het is PHP), maar ondertussen is het precies het Java waar ze 10 jaar geleden zo tegen aan schopte (want te moeilijk).

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
flowerp schreef op zondag 01 januari 2006 @ 12:13:
Inderdaad. Op wat kleinere dingetjes na (zoals de deployment), overtreed Ruby toch wel z'n eigen DRY regel. Dingen zoals MVC, OR mapping en andere zaken bestaan gewoon al in Java. Waarom alles overnieuw uitvinden als Java het al heeft? Wie is nou zichzelf aan het repeaten?
Uhm, ik ken genoeg mensen die Ruby een mooiere taal vinden dan Java. Het feit dat iemand in Java al een keer het MVC pattern en OR mapping heeft gebruikt betekent natuurlijk niet dat andere talen dat niet mogen implementeren. Bovendien zijn OR mapping en MVC gewoon ideeen en absoluut niet uniek voor Java. Dat DRY slaat alleen op Rails/Ruby zelf, maar dit had je hoop ik zelf ook wel door.
Had het development team van Ruby mischien niet beter een JSR kunnen leiden die de hot-deployment van classen in Java regelt?
Ruby != Rails. Dit soort vragen moet je bij een partij als Sun neerleggen, maar dit is gewoon offtopic geneuzel in een Ruby on Rails thread....

Acties:
  • 0 Henk 'm!

  • flowerp
  • Registratie: September 2003
  • Laatst online: 20-05 21:31
smesjz schreef op zondag 01 januari 2006 @ 12:36:
[...]

Uhm, ik ken genoeg mensen die Ruby een mooiere taal vinden dan Java. Het feit dat iemand in Java al een keer het MVC pattern en OR mapping heeft gebruikt betekent natuurlijk niet dat andere talen dat niet mogen implementeren.
Klopt, maar een web platform is nogal groot en Ruby on Rails is gewoon een direct alternatief voor Java EE. Het is een beetje te kinderachtig om in termen van "jullie hebben het, dus wij mogen het ook!" te denken, dat zie je toch zelf ook wel in smesjz?

Waar het om gaat, is dat het mischien een beetje zonde is om zo'n enorme software stack overnieuw te ontwikkelen als je maar enkele dingen toevoegd en relatief veel meer dupliceert. Ik mis bijvoorbeeld operator overloading in Java. Moet ik daarom maar een complete software stack voor web applications in C++ gaan schrijven (en daarmee al het werk van servlets, jsp, jsf, hibernate/EJB, etc etc overnieuw doen) alleen zodat ik iets lekkerdere syntax tot mijn beschikking heb?

Tuurlijk, er zijn mensen die Ruby als taal mooier vinden. Ik vind C++ als taal mooier, en een 3de persoon vind Objective-C weer stukken mooier. Elke profesional weet dat de programmeer taal zelf maar een klein onderdeel van het totale development plaatje vormt (tenzij het over totaal andere soorten talen gaat als functioneel en logisch). De frameworks en libraries spelen een veel grotere rol.

Was een Ruby compiler voor .NET en de Sun VM mischien niet makkelijker geweest?

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

flowerp: Nou én :? . Ik vind het geweldig om mee te werken, de taal veel prettiger, het framework (veel) beter, en vooral prettiger!, dan enig framework wat ik ken. Ik vind het prettiger om in te ontwikkelen, en voor wat ik ermee doe bespaar ik er een enorme hoeveelheid tijd en een enorme hoeveelheid regels code (en ja, dat is gewoon gemak) mee. Dat maakt het voor mij geweldig om te gebruiken, en kennenlijk voor een heleboel andere mensen ook. Wat is dus in vredesnaam het probleem :? . Er bestaan veel te veel frameworks, en misschien was het makkelijker geweest om het in taal x te doen, of op platform y , maar het is nu eenmaal in deze taal geschreven. En persoonlijk ben ik daar erg blij mee :) .

DM!


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
flowerp schreef op zondag 01 januari 2006 @ 13:01:
Klopt, maar een web platform is nogal groot en Ruby on Rails is gewoon een direct alternatief voor Java EE. Het is een beetje te kinderachtig om in termen van "jullie hebben het, dus wij mogen het ook!" te denken, dat zie je toch zelf ook wel in smesjz?
Ik dacht dat je het serieus bedoelde omdat je typte dat 'RoR zich niet houdt aan zijn eigen DRY principe'. Anyway.
Waar het om gaat, is dat het mischien een beetje zonde is om zo'n enorme software stack overnieuw te ontwikkelen als je maar enkele dingen toevoegd en relatief veel meer dupliceert. Ik mis bijvoorbeeld operator overloading in Java. Moet ik daarom maar een complete software stack voor web applications in C++ gaan schrijven (en daarmee al het werk van servlets, jsp, jsf, hibernate/EJB, etc etc overnieuw doen) alleen zodat ik iets lekkerdere syntax tot mijn beschikking heb?
Dat is onzin natuurlijk. Bij nieuwe projecten __kan__ RoR een overweging zijn. Bovendien is het gewoon een tool om een probleem op te lossen en als dat probleem sneller op te lossen in Java omdat je daar al zelf een software stack voor hebt geschreven die snel in te zetten is, moet je dat vooral doen. Bovendien is operator overloading nou niet echt een show-stopper.

Ik gebruik geen J2EE of .net en heb vooral ervaring met Perl, Python, PHP en Ruby. Iedere taal heeft wel zijn eigenaardigheden of beperkingen, maar dat moet je gewoon creatief mee omgaan.
Tuurlijk, er zijn mensen die Ruby als taal mooier vinden. Ik vind C++ als taal mooier, en een 3de persoon vind Objective-C weer stukken mooier. Elke profesional weet dat de programmeer taal zelf maar een klein onderdeel van het totale development plaatje vormt (tenzij het over totaal andere soorten talen gaat als functioneel en logisch). De frameworks en libraries spelen een veel grotere rol.
Klopt, sommige expressies kan ik Ruby sneller/mooier doen dan in bijv. C++, Java, PHP. Het framework van Rails is tot nu toe het meest uitgebereide framework waar ik mee heb gewerkt EN waar ik toch snel in kan ontwikkelen. De libraries die Ruby kan gebruiken zijn vaak gebaseerd op de C-libraries die gemakkelijk via Ruby benaderd kunnen worden. Buiten de standaard XML libraries kan je ook libxml/libxslt gebruiken.
Standard Library voor Ruby is misschien niet zo uitgebreid als die van Java, maar de userbase van Ruby en Rails is ook een stuk kleiner dan die van Java. Toch biedt de stdlib voldoende mogelijkheden en zijn er natuurlijk ook genoeg libraries te gebruiken die niet in de stdlib of core zitten van Ruby.
Was een Ruby compiler voor .NET en de Sun VM mischien niet makkelijker geweest?
Waarom? Rails is in eerste instantie een web framework en bovendien vraag ik me af waarom Ruby die .net en Sun VM nodig heeft?
Het compilen van Ruby apps gaat ook wel hoor, alleen het gebeurt niet tijdens runtime. Is dat erg? Nee. Ik denk ook niet dat Rails het nodig heeft. Nu wordt Apache 2.2's FastCGI in de core opgenomen en kan mod_ruby straks zonder problemen meerdere instanties van Rails aan.

Qua geheugengebruik is Rails nog erg vriendelijk vind ik, dus misschien kunnen de Java app. servers weer iets van leren?

Acties:
  • 0 Henk 'm!

Verwijderd

flowerp schreef op zondag 01 januari 2006 @ 12:13:
Inderdaad. Op wat kleinere dingetjes na (zoals de deployment), overtreed Ruby toch wel z'n eigen DRY regel. Dingen zoals MVC, OR mapping en andere zaken bestaan gewoon al in Java. Waarom alles overnieuw uitvinden als Java het al heeft? Wie is nou zichzelf aan het repeaten?

Had het development team van Ruby mischien niet beter een JSR kunnen leiden die de hot-deployment van classen in Java regelt?
Er is al veel discussie hierover geweest of andere niet-dynamische talen ook iets als rails hadden kunnen maken. Ik denk zelf dat Ruby als taal ook veel voordelen met zich meebrengt... (zoek maar even naar de blogs over could rails have been done in a other language then ruby ofzo)..

--edit--
Nog een heel belangerijk punt is dat rails zo heerlijk eenvoudig is uit te breiden. De code is lekker leesbaar (en een stuk minder loc dan vergelijkbare projecten), ik zit regelmatige in de core dingen te lezen welke ik hier en daar in plugins voormezelf uitbreid.

Met java lukte mij dat nooit, voordat je hibernate door had, was je 24 uur verder en voordat je de core snapte was je een week verder (om maar een voorbeeld te noemen). Ik merk daarnaast dat ruby als taal mijn productiviteit enorm vergroot. De kleine zaken maken het verschil...

[ Voor 27% gewijzigd door Verwijderd op 01-01-2006 15:03 ]


Acties:
  • 0 Henk 'm!

Verwijderd

flowerp schreef op zondag 01 januari 2006 @ 13:01:
[...]

Waar het om gaat, is dat het mischien een beetje zonde is om zo'n enorme software stack overnieuw te ontwikkelen als je maar enkele dingen toevoegd en relatief veel meer dupliceert. Ik mis bijvoorbeeld operator overloading in Java. Moet ik daarom maar een complete software stack voor web applications in C++ gaan schrijven (en daarmee al het werk van servlets, jsp, jsf, hibernate/EJB, etc etc overnieuw doen) alleen zodat ik iets lekkerdere syntax tot mijn beschikking heb?
Het implementeren van hibernate/(bestaande mcv/enz) in ruby zou echt niet zo lekker werken als ActiveRecord. Het is gewoon anders gebouwd (hoewel het minder krachtig dan hibernate is). Veel nadelen neem ik juist voor lief omdat actionpack al die zaken voor mij op een prettige manier combineerd.

En EJB's wil ik helemaal nooit meer zien..

Acties:
  • 0 Henk 'm!

  • flowerp
  • Registratie: September 2003
  • Laatst online: 20-05 21:31
Omdat je dan bouwt op een common foundation en niet voor veel dingen het wiel opnieuw uit gaat vinden. Let op mijn woorden, er gaan Ruby compilers komen. Deze compilers gaan dan het hele traject van optimalisaties en concurrent werkende GC's weer overnieuw doorlopen. Compileer naar .NET en JVM en je krijgt al deze optimalisaties er gratis bij.

Je kunt je dan concentreren op de dingen die jouw produkt uniek maken, zonder dan maar meteen 100 andere (noodzakelijke) dingen overnieuw te doen.

Maar goed, laten we deze lijn van de discussie niet te ver uit de hand laten lopen. Het was niet mijn bedoeling om overdreven negatief t.o.v. Ruby en Rails te gaan staan. Waar het me een beetje om ging was dat nieuwe dingen te vaak gehyped beginnen en dan als main argument hebben dat het makkelijker is. Vaak zie je dan dat het niet an-sich makkelijker is, maar dat het product nog gewoon jong en onvolledig is. Na verloop van tijd groeit de techniek, en neemt het van alles over van de oude techniek de eerst zo gebashed werden.

Java zelf heeft dat ook gehad hoor!

Toen Java in 1996 bekend begon te worden was er ook zo'n hype om. Write Once Run Everywhere brulde de ene groep. Makkelijke syntax brulde weer een andere groep. Overzichtelijke library riep een derde. Vooral C++ moest het toen ontgelden. Allemaal mensen die opeens in Java wilde programeren, want die exceptions vonden ze veel makkelijker (zat ook gewoon in C++), en die actionListeners waren zo makkelijk (library opzet, had niks met Java zelf te maken), en dat Run Everywhere was ook zo gigantisch (werkte in de praktijk toch niet 100%, en men had net zo goed een VM kunnen maken waar C++ heen compilede zoals herb sutter & z'n team bij MS nu gedaan hebben). De syntax van Java kreeg toch later wel de varidadic arguments, enums en generics die er eerst niet in mochten omdat het geen C++ mocht zijn en de library is ondertussen zo gegroeid dat het allang niet meer overzichtelijk is.

Met PHP zie ik nu exact hetzelfde gebeuren. In het begin mocht het geen classes hebben, want dat vonden prutsers te moeilijk. Toen bleek dat het toch wel lastig programmeerde zonder OOP hebben ze het toch maar toegevoegd. Universele DB access geloofde ze ook niet echt in (in de zin van ODBC/JDBC achtige toegang). MySQL was toch goed genoeg en bovendien gratis? Nu komen ze daar toch op terug omdat lock-in op 1 enkele DB toch wel lastig is in de praktijk.

Daarom ben ik dus HEEL ERG SCEPTISCH als er WEER een nieuwe techniek gehyped wordt, met het voornaamste argument "makkelijk". Nu kan RoR waarschijnlijk nog klein en simpel gehouden worden vanwege het lage aantal stakeholders. Maar laat het maar eens groeien. Steeds meer mensen die van alles en nog wat willen wat toch weer niet helemaal kan. Je zult zien dat er weer van alles toegevoegd gaat worden en dat over 10 jaar er opeens "Diamond" komt wat weer enorm gehyped wordt. Ruby zal dan afgeschilderd worden als te moeilijk en te zwaar en iedereen zal naar Diamond overstappen. Gedeeltelijk heb je te maken met dingen als vooruitgang en dat is alleen maar goed, maar als vooruit gang bestaat uit het -terug gaan- naar een staat van de techniek van enkele jaar terug en het dan weer vervolgens aangroeid tot dat wat men eerst verlaten had, dan heb je een zinloze serie cycles van overstappen.

Er zijn maar weinig platformen die iets -echt- makkelijk kunnen maken kwa concept, en niet gewoon door het feit dat het een 0.1 versie is waar gewoon veel dingen missen. Spring is mischien zo'n platform, en voor eind gebruikers wellicht de verschillende Apple produkten.

Rest me nog te zeggen dat als Ruby de nieuwe "perceived" (*) makkelijkheid krijgt toegedicht, dat mensen die eigenlijk niet willen leren programmeren dan beter zich tot Ruby kunnen laten overhalen dan naar PHP. Ruby zit tenminste -wel- mooi in elkaar.


* Vaak gaat het mensen er niet om of dingen -echt- makkelijker zijn, maar dat iedereen -zegt- dat het makkelijk is. Als er maar vaak wordt geroepen dat iets makkelijk is (zonder onderbouwing waarom dat dan makkelijker is), dan -vinden- mensen het ook makkelijker. Iedereen roept nu dat Java zo moeilijk is en PHP zo makkelijk, terwijl een JSP en een PHP pagina nagenoeg identiek zijn. Java -kan- meer, maar de beginner hoeft dat absoluut niet te gebruiken. Met een auto kun je ook aardig wat advanced stuntwerk doen, maar iemand die alleen zaterdag de boodschappen doet met de auto hoeft zich daar helemaal niet in te verdiepen.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

flowerp: Misschien is het juist wel goed dat het zo gaat, en houd dat de ontwikkeling en "makkelijke dingen" in gang. Ik moet nu gaan, zal vanmiddag wel een uitgebreider verhaaltje tikken... Je zegt dat mensen steeds overstappen op een nieuw gehypde taal / framework overstappen omdat dat makkelijker is, en dat dat framework daarna om alle nieuwe users te pleasen bulky wordt, waardoor mensen weer overstappen op een nieuw systeem. Dat komt volgens mij voort uit het feit dat het moeilijk is meerdere gebruikersgroepen tevreden te houden. Sommigen willen zo'n bulky systeem, maar niet té, en sommige mensen hebben de behoefte aan zo'n lean systeem. Kennenlijk hebben systemen de neiging naar de tijd vordert bulky te worden. Dus vindt er overstap plaats. En dat doet niks af aan het feit dat het wel degelijk makkelijker is, en voor de groep mensen die behoefte heeft aan het leane of op andere vlak betere systeem systeem prettiger. Wat niet wil zeggen dat iedereen moet overstappen.

En dat is volgens mij sowieso een denkfout. RoR is geweldig voor de applicaties die ík maak. Of het voor enterprise-level business-critical etc. etc. systemen ook het beste systeem weet ik niet. Sommigen vinden van wel, en andere van niet. Daar zal je zelf je afweging bij moeten maken, en daarvoor zal je óf het zelf moeten uitzoeken, óf moeten wachten tot het ouder is, daarmee het risico nemende dat het al een minder goed product is (of juist een beter!).

[ Voor 77% gewijzigd door JHS op 01-01-2006 19:29 ]

DM!


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
flowerp schreef op zondag 01 januari 2006 @ 15:13:
[...]


Omdat je dan bouwt op een common foundation en niet voor veel dingen het wiel opnieuw uit gaat vinden. Let op mijn woorden, er gaan Ruby compilers komen. Deze compilers gaan dan het hele traject van optimalisaties en concurrent werkende GC's weer overnieuw doorlopen. Compileer naar .NET en JVM en je krijgt al deze optimalisaties er gratis bij.
Ruby's GC is nog niet optimaal en in de aankomende 1.9 zijn in ieder geval wat verbeteringen toegevoegd aan het mark-and-sweep algoritme. Optimalisaties en concurrent werkende GC's zullen ongetwijfeld leuk zijn maar als je echt iets snels wil gebruik geen taal als Ruby of .net.
Je kunt je dan concentreren op de dingen die jouw produkt uniek maken, zonder dan maar meteen 100 andere (noodzakelijke) dingen overnieuw te doen.
Het fijne van Rails is al dat iemand anders (developers Rails) dat al hebben gedaan. Rails is nog jong, nog hip en heeft ook wel wat last van groeipijntjes.
Maar goed, laten we deze lijn van de discussie niet te ver uit de hand laten lopen. Het was niet mijn bedoeling om overdreven negatief t.o.v. Ruby en Rails te gaan staan. Waar het me een beetje om ging was dat nieuwe dingen te vaak gehyped beginnen en dan als main argument hebben dat het makkelijker is. Vaak zie je dan dat het niet an-sich makkelijker is, maar dat het product nog gewoon jong en onvolledig is. Na verloop van tijd groeit de techniek, en neemt het van alles over van de oude techniek de eerst zo gebashed werden.

Java zelf heeft dat ook gehad hoor!
Zo lang IK met veel plezier en vlot in Rails kan ontwikkelen maken mij de veranderingen niet veel uit. Natuurlijkt leent Ruby en ook Rails goede ideeen van andere talen, het zou dom zijn om het wiel opnieuw uit te vinden. Maar de Ruby/Rails manier is dan om bijv. OR mapping aan te bieden met minder 'moeite' dan in andere talen. Take or leave it :)
Met PHP zie ik nu exact hetzelfde gebeuren. In het begin mocht het geen classes hebben, want dat vonden prutsers te moeilijk. Toen bleek dat het toch wel lastig programmeerde zonder OOP hebben ze het toch maar toegevoegd. Universele DB access geloofde ze ook niet echt in (in de zin van ODBC/JDBC achtige toegang). MySQL was toch goed genoeg en bovendien gratis? Nu komen ze daar toch op terug omdat lock-in op 1 enkele DB toch wel lastig is in de praktijk.
Van PHP vind ik het wel goed dat ze ook eindelijk een begin maken met OOP, alleen het is gewoon inherent aan PHP dat je geen classes hebt voor string en integer manipulatie. En dat kan soms wel eens wennen zijn. Verder snap ik je database lock in niet helemaal. Iets wat in JDBC wel cool is en ik nog niet in andere drivers heb gezien, is bijv. de ondersteuning voor een failoverhost.

In ruby kan je bijv. dit doen (kan vast ook in andere talen):
code:
1
2
3
4
5
def foo
   [1,2]
end

foo[0]

In PHP moet je dan eerst de return value van een functie die een array teruggeeft opslaan in een lokale variabele. (Probeer dat bovenstaande maar eens in Java :>)
Daarom ben ik dus HEEL ERG SCEPTISCH als er WEER een nieuwe techniek gehyped wordt, met het voornaamste argument "makkelijk". Nu kan RoR waarschijnlijk nog klein en simpel gehouden worden vanwege het lage aantal stakeholders. Maar laat het maar eens groeien. Steeds meer mensen die van alles en nog wat willen wat toch weer niet helemaal kan. Je zult zien dat er weer van alles toegevoegd gaat worden en dat over 10 jaar er opeens "Diamond" komt wat weer enorm gehyped wordt.
Ik geloof niet dat er veel rotzooi in Rails gaat komen, het team committers is klein. Bovendien wordt de ontwikkeling niet gestuurd door een bedrijf dat targets moet halen. Dat het in de toekomst misschien anders is, kan best dat "Diamond" dan geweldig is en dat ik dat dan ga gebruiken. Sommige talen moet gewoon eerst volwassen worden. Bij Rails heb ik gewoon een goed gevoel dat ik het in de toekomst nog gebruik.

Talen maken gewoon ontwikkelingen door en misschien ga ik straks wel weer iets in C++ schrijven. Ik weet het niet.

Like I said, het ligt maar net aan probleem welke taal, dbase het meest geschikt is. Ik heb ook een tijd gekeken naar Roundcube webmail, erg mooi design en ook helemaal de shit want het gebruikte Ajax voor o.a.uploads en koppeling met een adresboek. Ik vond het ook helemaal geweldig totdat ik wat extra features wilde maken (server-side sorting en threading) en ik al snel tegen een boel spaghetti code aanliep. Het is natuurlijk wel afhankelijk van de programmeur die een taal gebruikt hoe (on)overzichtelijk het wordt.

Acties:
  • 0 Henk 'm!

Anoniem: 58567

smesjz schreef op zondag 01 januari 2006 @ 21:13:

In ruby kan je bijv. dit doen (kan vast ook in andere talen):
code:
1
2
3
4
5
def foo
   [1,2]
end

foo[0]

In PHP moet je dan eerst de return value van een functie die een array teruggeeft opslaan in een lokale variabele. (Probeer dat bovenstaande maar eens in Java :>)
Ben ik nou de enige die gaat kotsen van deze syntax?

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Anoniem: 58567 schreef op zondag 01 januari 2006 @ 21:31:
[...]


Ben ik nou de enige die gaat kotsen van deze syntax?
Pff, zo erg is het toch niet? Bij ruby is alles wat tussen blokhaken staat een array en is de laatste assignment van een method, als het 'return' keyword ontbreekt ook meteen de return value.

Dit was wel erg kort door de bocht misschien, maar daar light misschien ook de kracht van talen als Perl en Python :)

Acties:
  • 0 Henk 'm!

Anoniem: 58567

smesjz schreef op zondag 01 januari 2006 @ 21:37:
[...]


Pff, zo erg is het toch niet? Bij ruby is alles wat tussen blokhaken staat een array en is de laatste assignment van een method, als het 'return' keyword ontbreekt ook meteen de return value.

Dit was wel erg kort door de bocht misschien, maar daar light misschien ook de kracht van talen als Perl en Python :)
Ik vind het aanroepen van functies zonder haakjes ook wel lelijk eigenlijk. Ruby is wat mij betreft sowieso te vrijblijvend: kom, we geven een method meerdere namen, haakjes hoeven niet, return hoeft niet; waarom wordt er niet gewoon een keuze gemaakt? Ik zie al gebeuren dat als je in een team werkt, of code 6 maanden niet meer gezien hebt, er problemen ontstaan.

Python is syntax-gewijs, in tegenstelling tot Ruby en Perl, wel goed. Leesbaar, duidelijk, en weinig ruimte voor discussie:
code:
1
2
3
4
def bla():
    return (1, 2)

bla()[0]

[ Voor 4% gewijzigd door Anoniem: 58567 op 01-01-2006 22:31 ]


Acties:
  • 0 Henk 'm!

  • RayNbow
  • Registratie: Maart 2003
  • Laatst online: 19:22

RayNbow

Kirika <3

smesjz schreef op zondag 01 januari 2006 @ 21:13:
In ruby kan je bijv. dit doen (kan vast ook in andere talen):
code:
1
2
3
4
5
def foo
   [1,2]
end

foo[0]

In PHP moet je dan eerst de return value van een functie die een array teruggeeft opslaan in een lokale variabele. (Probeer dat bovenstaande maar eens in Java :>)
Java:
1
2
3
4
5
6
7
8
9
10
11
12
public class Test {

    private static int[] foo() {
        return new int[]{1, 2};
    }

    public static void main(String[] args) {
        // Dit werkt gewoon in Java?
        System.out.println( foo()[0] );
    }

}

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Anoniem: 58567 schreef op zondag 01 januari 2006 @ 22:31:
[...]


Ik vind het aanroepen van functies zonder haakjes ook wel lelijk eigenlijk. Ruby is wat mij betreft sowieso te vrijblijvend: kom, we geven een method meerdere namen, haakjes hoeven niet, return hoeft niet; waarom wordt er niet gewoon een keuze gemaakt? Ik zie al gebeuren dat als je in een team werkt, of code 6 maanden niet meer gezien hebt, er problemen ontstaan.

Python is syntax-gewijs, in tegenstelling tot Ruby en Perl, wel goed. Leesbaar, duidelijk, en weinig ruimte voor discussie:
code:
1
2
3
4
def bla():
    return (1, 2)

bla()[0]
In Ruby kan je "return" ook gebruiken hoor, het hoeft alleen niet. Ik doe het vaak wel ivm leesbaarheid. Perl kan je ook leesbaar houden hoor.

code:
1
2
3
4
5
def foo()
  return [1,2]
end

puts foo()[0]

[ Voor 6% gewijzigd door smesjz op 01-01-2006 23:24 . Reden: Ruby uitbereiding ]


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
RayNbow schreef op zondag 01 januari 2006 @ 22:44:
[...]

Java:
1
2
3
4
5
6
7
8
9
10
11
12
public class Test {

    private static int[] foo() {
        return new int[]{1, 2};
    }

    public static void main(String[] args) {
        // Dit werkt gewoon in Java?
        System.out.println( foo()[0] );
    }

}
Ik bedoelde niet dat het niet kan in Java, maar gewoon dat je in Ruby je relatief weinig hoeft te typen t.o.v. andere talen. Dat kan soms een voordeel zijn.

Acties:
  • 0 Henk 'm!

Anoniem: 58567

smesjz schreef op zondag 01 januari 2006 @ 23:21:
[...]


In Ruby kan je "return" ook gebruiken hoor, het hoeft alleen niet. Ik doe het vaak wel ivm leesbaarheid. Perl kan je ook leesbaar houden hoor...
En ik heb dus problemen met die vrijblijvendheid. Als je weet dat de ene manier beter is, waarom wordt de andere manier dan ondersteund? Er zijn altijd malloten die kiezen voor het minste type-werk; als jij vervolgens die code moet aanpassen, ben je de pineut. Het gaat niet alleen om return, er zijn nog wel meer design-keuzes bij Ruby, waar ik grote problemen mee
heb.

/edit:
smesjz schreef op zondag 01 januari 2006 @ 23:27:
[...]


Ik bedoelde niet dat het niet kan in Java, maar gewoon dat je in Ruby je relatief weinig hoeft te typen t.o.v. andere talen. Dat kan soms een voordeel zijn.
Bovendien kan je in Java moeilijk 2 waarden met verschillende typen retourneren. Daar was laatst nog een topic over geloof ik.

[ Voor 26% gewijzigd door Anoniem: 58567 op 01-01-2006 23:33 ]


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Anoniem: 58567 schreef op zondag 01 januari 2006 @ 23:31:
[...]


En ik heb dus problemen met die vrijblijvendheid. Als je weet dat de ene manier beter is, waarom wordt de andere manier dan ondersteund? Er zijn altijd malloten die kiezen voor het minste type-werk; als jij vervolgens die code moet aanpassen, ben je de pineut. Het gaat niet alleen om return, er zijn nog wel meer design-keuzes bij Ruby, waar ik grote problemen mee
heb.
Dan kan je beter niet Ruby gebruiken. Ik vind de uitgebreide manier niet beter of slechter dan de compacte. Je hebt bij Ruby bijv. wel conventies, functies die een boolean teruggeven eindigen met een vraagteken waardoor je hele leesbare code houdt:

{"a"=>1,"b"=>2}.has_key?('a')

Dat vraagteken heeft geen enkele syntactische betekenis.

Functies die werken als setter eindigen met een '=' bijv.

Welke design keuzes vind je dan nog meer problematisch?
Bovendien kan je in Java moeilijk 2 waarden met verschillende typen retourneren. Daar was laatst nog een topic over geloof ik.
In dit geval gaat het om twee integers, niks bijzonders. In een normale reactie zul je het weinig zien, maar het is gewoon handig dat het in Ruby werkt zoals je hoopt dat het werkt. Zonder al te veel fratsen met type-conversion bijv.

Het coole van Ruby is bijv. de Fixnum class:

irb(main):008:0> 2.next
=> 3
irb(main):009:0> 2.integer?
=> true
irb(main):012:0> 2.upto(10) do |t| puts t
irb(main):013:1> end

Leuke gimmicks hoor :)

Acties:
  • 0 Henk 'm!

  • TlighT
  • Registratie: Mei 2000
  • Laatst online: 28-05 10:31
Anoniem: 58567 schreef op zondag 01 januari 2006 @ 22:31:
[...]


Ik vind het aanroepen van functies zonder haakjes ook wel lelijk eigenlijk. Ruby is wat mij betreft sowieso te vrijblijvend: kom, we geven een method meerdere namen, haakjes hoeven niet, return hoeft niet; waarom wordt er niet gewoon een keuze gemaakt? Ik zie al gebeuren dat als je in een team werkt, of code 6 maanden niet meer gezien hebt, er problemen ontstaan.
Een van de design principes van Ruby is juist de flexibiliteit van de syntax. Bovendien krijg je weer andere problemen als methods perse met haakjes moeten, aangezien bijna alles in Ruby een method is, ook bijvoorbeeld operators. Je zou dan verplicht krijgen:
code:
1
2
foo = Foo.new
foo.bar = (20)

omdat bar= een method is van Foo.

De flexibele syntax maakt het imho vaak ook duidelijker; persoonlijk vind ik bij eenregelige if's de notatie:
code:
1
foo=2 if bar>10

duidelijker dan:
code:
1
if bar>10 foo=2
En wat de leesbaarheid van andermans code... als je weet hoe de syntax van Ruby werkt dan is code van anderen wat betreft de syntax gewoon leesbaar (*zo* flexibel is het nou ook weer niet). Dan heb ik bijvoorbeeld meer problemen met die halfbakken OO implementatie van Python, zonder bijv. fatsoenlijke private en protected methods. Dat soort dingen zijn veel ingrijpender dan of een return nou wel of niet verplicht is.

Persoonlijk vind ik Ruby een heerlijk taaltje, het heeft bij mij in ieder geval Perl en Python al vervangen als scriptingtaal. Met RoR ben ik pas net begonnen. Zoals ik het nu zie is RoR een verbetering t.o.v. PHP, maar ik betwijfel of het echt geschikt is voor meer enterprise-achtige applicaties (vergeleken met Java en .NET).

[ Voor 9% gewijzigd door TlighT op 02-01-2006 00:11 ]


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
TlighT schreef op maandag 02 januari 2006 @ 00:07:
Persoonlijk vind ik Ruby een heerlijk taaltje, het heeft bij mij in ieder geval Perl en Python al vervangen als scriptingtaal. Met RoR ben ik pas net begonnen. Zoals ik het nu zie is RoR een verbetering t.o.v. PHP, maar ik betwijfel of het echt geschikt is voor meer enterprise-achtige applicaties (vergeleken met Java en .NET).
Bij Python vind ik het jammer dat je overal met dat 'this' loopt te hanessen. Bij Ruby kan je ook wel 'self' gebruiken, maar..je raadt het al..dat hoeft niet :)

Toch zijn er veel mooie Python apps gemaakt, zoals Trac en Moinmoin (wiki). Je ziet wel dat er sneller python bindings komen dan voor Ruby...

Acties:
  • 0 Henk 'm!

  • flowerp
  • Registratie: September 2003
  • Laatst online: 20-05 21:31
TlighT schreef op maandag 02 januari 2006 @ 00:07:
De flexibele syntax maakt het imho vaak ook duidelijker; persoonlijk vind ik bij eenregelige if's de notatie:
code:
1
foo=2 if bar>10

duidelijker dan:
code:
1
if bar>10 foo=2
Het is in iedergeval grappig 'anders'. Je ziet toch dikwijls dat alle talen die zogenaamd anders zijn voor 90% naar de C syntax style neigen. Zelfs PHP is in essentie toch gewoon de C-style syntax met hier en daar wat dollar tekens er door heen gemixed.

Nu is ruby niet gruwelijk anders (zoals bv schema, prolog, of postscript wel -echt- anders is), maar het is toch wel weer een leuke twist voor mensen die weer eens wat anders willen.

Je kunt in de meeste C-style talen deze merkwaardige postfix notatie een beetje nadoen door de ternaire conditionele expressie te gebruiken:

code:
1
foo = bar>10? 2 : bar;


In het algemeen wordt deze style van de programmeren wel als slecht bestempeld. Conditionele statements zijn explicieter en beter uitbreidbaar (dwz, makkelijker als er aan de hand van de conditie later 'opeens' nog wat meer moet gebeuren dan eerst voorzien was).

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
flowerp schreef op maandag 02 januari 2006 @ 00:30:
Je kunt in de meeste C-style talen deze merkwaardige postfix notatie een beetje nadoen door de ternaire conditionele expressie te gebruiken:

code:
1
foo = bar>10? 2 : bar;


In het algemeen wordt deze style van de programmeren wel als slecht bestempeld. Conditionele statements zijn explicieter en beter uitbreidbaar (dwz, makkelijker als er aan de hand van de conditie later 'opeens' nog wat meer moet gebeuren dan eerst voorzien was).
Ik vind het niet zo zeer slecht. Voor hele simpele if's kan het nog wel eens fijn werken, maar echt fijn leest het natuurlijk niet. Het bovenstaande statement omklussen naar een regulier if statement is natuurlijk ook niet veel moeite. Maar we gaan nu wel heel erg offtopic :)

Ontopic dan maar even: wat vinden jullie de meest coole method in Rails?

Ik zelf vind dynamische methods uit Activerecord::base (find_*) die via de method_missing de SQL statements maken:

Person.find_by_user_name_and_password(user_name, password).

Het bevordert de leesbaarheid en natuurlijk kan je altijd je eigen SQL statements gebruiken:
Person.find_by_sql("SELECT user_name,password FROM ... ")

Acties:
  • 0 Henk 'm!

Verwijderd

Zaken als modules en mixins vind ik overgens ook geweldig hoewel soms een beetje gevaarlijk/krachtig.

Sommige dingen in ruby vind ik niet helemaal lekker zoals laatste value is de return value, maar dat zijn kwestie's van smaak. Je kunt een return meegeven, maar je kunt ervoor kiezen dat de laatste value een return geeft.

Qua framework blijft rails toch een zeer speciaal iets in de branche, net als Seaside of een van de velen rails varianten. Ik heb overgens wel bijna een half jaar rails zitten evalueren naast bestaande php/java omgevingen voordat ik ben overgestapt.

Acties:
  • 0 Henk 'm!

Verwijderd

Bij het lezen van dit hele topic bespeur ik toch weinig concreets. Er wordt hier en daar wat ingegaan op de syntax en wat geroepen door Java'ers. Maar kijkend vanuit ontwikkelend opzicht, ben ik toch meer op zoek naar antwoorden op vragen als 'kan ik met RoR sneller ontwikkelen dan met PHP? Wat zijn de beperkingen van RoR? Als ik een ingewikkelde en grote webapplicatie wil maken, is het voor mij een alternatief?'

Ikzelf ben nu wat weekjes bezig met RoR, en ben er erg positief over. Bij het ontwikkelen van wat kleine test-applicaties valt met het gemak op en valt vooral het 'in php moest ik dit inderdaad elke keer opnieuw doen'-gevoel weg. Boek is nu besteld en hopelijk krijg ik snel wat meer duidelijkheid over het hoe en wat van Rails.

Acties:
  • 0 Henk 'm!

  • EdwinV
  • Registratie: Januari 2004
  • Laatst online: 18-04 15:08
Ik ben nu ook een paar weken bezig met wat knutselen in Ruby on Rails. Over het algemeen ben ik zeer te spreken over de mogelijkheden die zowel de taal als het framework te bieden hebben. Toch loop ik ook tegen beperkingen op.

Zo kan je in modellen heel netjes aangeven welke validatie voorwaarden je wilt toepassen op de kolommen. Rails geeft je een manier om na het invoeren van een formulier eventuele validatie fouten weer te geven. Er bestaat echter geen manier om tijdens het aanmaken van een formulier al aan te geven welke velden welke voorwaarden hebben. Het model kan je niet bevragen naar dit soort eigenschappen. Voor een goede interface zou ik op z'n minst willen aangeven welke velden een gebruiker zoiezo moet invoeren. Een uitbreiding hierop is een JavaScript controle op de validaties, zodat je een extra pagina vernieuwing kunt voorkomen.

Een andere beperking is de indeling waar je aan vast zit. Ik ben gewend om in PHP met modules te werken. Elke modules heeft een eigen map indeling met de PHP bestanden, sjablonen en eventueel extra bestanden. In RoR heb ik nog geen manier gevonden om dit voor elkaar te krijgen. Wat ik graag zou zien is een manier om voor verschillende onderdelen in een website een map structuur models/views/controllers te hebben, zodat code makkelijker terug te vinden is en een model simpel in te voegen is in een applicatie.

Dit laatste geval kan een kwestie van onkunde van mijn kant zijn, maar ik heb alle documentatie al doorgelezen en heel wat wiki's doorgespit. Tot nu toe heb ik geen manier gevonden om dit aan te pakken.

De overstap van PHP naar RoR is soms wat wennen, maar het is een genot om veel minder werk te hoeven doen en toch hetzelfde resultaat te kunnen bereiken.

Acties:
  • 0 Henk 'm!

Verwijderd

Powerp en anderen: Vergeet niet dat Ruby al 10 jaar oud is. deze ontwikkel periode heeft ruby dus gedeeld met Java, php (.net bestond niet eens bestond asp al?)

De basis van het Rails Framework is in weekje geschreven volgens de maker, hij heeft hetzelfde framework ook in php geprobeerd te maken maar liep tegen te veel problemen op (heb niet gezien welke problemen).

Maar het grootste voordeel ligt denk ik nog steeds in de tijdwinst.

Classes in php5 zijn trouwens best ok, alleen php5 wordt ook nog niet zo ontzettend breed ondersteund.

Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 20-07 13:40
@flydesign: ik denk dat je af moet stappen van het idee dat je met PHP o.i.d. werkt. Als je echt effectief met RoR wilt werken zal je over moeten stappen op de manier van werken zoals die in Ruby bestaat. Als je hetzelfde wilt doen als ik PHP heb je alleen de syntactische voordelen en zal je uiteindelijk meer frustraties dan voordelen hebben.

Acties:
  • 0 Henk 'm!

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 09-06 06:07

JHS

Splitting the thaum.

Flydesign.nl schreef op maandag 02 januari 2006 @ 17:07:
Voor een goede interface zou ik op z'n minst willen aangeven welke velden een gebruiker zoiezo moet invoeren. Een uitbreiding hierop is een JavaScript controle op de validaties, zodat je een extra pagina vernieuwing kunt voorkomen.
Dat eerste kost nu inderdaad wat tikwerk. Je moet in je .rhtml een tekstje maken met "Your username must be present and can be max. 50 characters". Maar dat vind ik niet echt een show-stopper, alhoewel het wel makkelijker zou zijn als dat automagisch gegenereerd zou worden.. Het tweede zit semi-in-the-box, alhoewel er wel een ajax request voor nodig is*, wat het eerste probleem al een stuk kleiner maakt :) .

DM!

Pagina: 1 2 3 4 5 Laatste