Gathering of Tweakers

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...

quote:

Timz 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.

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
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 Scheelt een berg werk zeg

SchizoDuckie wijzigde dit bericht 20-12-2005 00:17 (9%)

quote:

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
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 Scheelt een berg werk zeg

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!

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

quote:

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.

quote:

kenneth schreef op dinsdag 20 december 2005 @ 08:10:
En als je per se in PHP wil blijven programmeren () 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

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 ;-)

Timz wijzigde dit bericht 20-12-2005 15:42 (25%)

quote:

Timz 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.

quote:

mark platvoet 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?

SchizoDuckie wijzigde dit bericht 20-12-2005 16:03 (3%)
Reden: sex met komma's

Rubyscript

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.

quote:

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.

quote:

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

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.

Mithrandir wijzigde dit bericht 20-12-2005 16:03 (9%)

Distributed transactions anyone?

quote:

mark platvoet schreef op dinsdag 20 december 2005 @ 16:10:
Distributed transactions anyone?

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]

quote:

mark platvoet 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.

Mithrandir wijzigde dit bericht 20-12-2005 16:26 (55%)

quote:

mark platvoet 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.

quote:

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.

quote:

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

quote:

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.

quote:

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.

quote:

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.

quote:

mark platvoet 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?

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.

quote:

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.

mark platvoet wijzigde dit bericht 20-12-2005 17:01 (36%)

.

Mithrandir wijzigde dit bericht 20-12-2005 17:06 (149%)

quote:

mark platvoet 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.

Mithrandir wijzigde dit bericht 20-12-2005 17:19 (7%)

quote:

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

quote:

beany schreef op dinsdag 20 december 2005 @ 17:07:
[...]


omfg

OMFGWTFROFL

?

[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.

Mithrandir wijzigde dit bericht 20-12-2005 17:18 (52%)

quote:

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.

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...

quote:

mark platvoet 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.

Mithrandir wijzigde dit bericht 20-12-2005 17:25 (5%)