Geplaatst door Danny Lagrouw
vr, 03 maa 2006 08:17:00 GMT
Een klacht die je vaak over Ruby hoort is het gebrek aan een geavanceerde ontwikkelomgeving met bijvoorbeeld refactoring tools. Is de acceptatie van een programmeertaal nu afhankelijk geworden van de beschikbaarheid van tools die de edele kunst van het programmeren terugbrengen tot het kiezen van de juiste refactoring uit een menuutje?
In een lang artikel op O’Reilly Ruby betoogt Steve Yegge dat we met geautomatiseerde refactoring een doel voorbij zijn geschoten. Natuurlijk is het mooi en handig, wat bijvoorbeeld Eclipse je op dit gebied biedt (in Java). Maar we zijn vergeten dat refactoring vaak een oplossing is voor een probleem dat we zelf hebben gecreëerd: code smell. Een probleem dat we dus ook vaak al in de kiem hadden kunnen smoren.
Of Ruby en Rails hier voordelen bieden boven andere talen en omgevingen (zoals Java/J2EE) weet ik niet. Veel soorten code smell zijn volgens mij universeel. Ik geloof dat het belangrijk is om dit soort problemen vroeg te herkennen en te voorkomen. En ik denk dat collegiale toetsing, of nog beter, pair programming, daar heel goed bij kunnen helpen.
En die vlinder? Daar zul je toch het oorspronkelijke artikel voor moeten doorlezen…
Geplaatst in ruby, blog | Tags refactoring | geen reacties
Geplaatst door Michiel de Mare
wo, 01 maa 2006 06:38:00 GMT
Als je herhaaldelijk op hetzelfde object verschillende methoden uitvoert die als laatste argument een hash met opties hebben waarvan een of meer steeds hetzelfde zijn (maar niet allemaal, want dan kun je beter steeds dezelfde hash gebruiken) – dan biedt with_options uitkomst.
Lees verder...
Geplaatst in ruby, ruby on rails | geen reacties
Geplaatst door Remco van 't Veer
ma, 27 feb 2006 01:26:00 GMT
Maar zeker ook niet verloren. Donderdag en vrijdag jl. hebben Michiel en ik als het Finalist RubyOnRails-team mee gedaan aan de RAD Race. We hebben het opgenomen tegen Oracle, Java en 4GL specialisten en hebben het voor een stel Java ontwikkelaars die in hun vrije tijd met Ruby spelen lang niet slecht gedaan.
Lees verder...
Geplaatst in ruby, ruby on rails, events | 1 reactie
Geplaatst door Michiel de Mare
za, 25 feb 2006 04:04:00 GMT
Later volgt nog een stukje over onze ervaringen op de RAD-race, eerst iets urgenters.
Een van de zwakke plekken van Ruby is het gebrek aan goede tools. In Java controleert IntelliJ je syntax tijdens het typen, zodat (in combinatie met refactoring) compileerfouten vrijwel tot het verleden behoren. Ruby heeft een IntelliR hard nodig, aangezien de code niet gecompileerd wordt, zodat je fouten pas tijdens het runnen van de tests (of erger, tijdens runtime) tegenkomt.
Wat Ruby wel heeft is het ‘ruby -c’ commando, dat de syntax van een Ruby-bestand controleert. Met het volgende commando controleer je al je Ruby-bestanden in je app directory:
find app -name *.rb -exec ruby -c '{}' \;
Je kunt ook je .rhtml-bestanden controleren. Eerst moet je ze converteren naar Ruby – dat doe je met het erb -x commando. Het hele commando gaat zo:
find app -name *.rhtml | ruby -e 'STDIN.each {|l|puts "echo #{l}erb -x #{l.chop} | ruby -c"}' > chk_syntax; chmod 775 chk_syntax; ./chk_syntax
Als we dat gisteren hadden gebruikt, had dat ons zeker een hoop punten gescheeld…
Geplaatst in ruby, ruby on rails | 1 reactie
Geplaatst door Danny Lagrouw
wo, 22 feb 2006 11:07:00 GMT
Terwijl Michiel en Remco op dit moment de laatste voorbereidingen treffen voor hun deelname aan de RAD Race (waar ze uiteraard met Rails gaan ontwikkelen), is een datum geprikt voor de eerste grote Nederlandse Ruby en Rails dag:
18 mei 2006 – RubyEnRails 2006
Deze dag wordt georganiseerd door Profict. Er zal in ieder geval een Workshop On Rails worden verzorgd door Remco en ondergetekende. Deze workshop biedt een allereerste introductie in de omgeving Rails en de taal Ruby.
Meer informatie komt binnenkort; houd deze site in de gaten!
Geplaatst in ruby, ruby on rails, nieuws, events | 4 reacties
Geplaatst door Remco van 't Veer
ma, 20 feb 2006 19:16:00 GMT
Vorige week maandag en donderdag hebben Michiel en ik een presentaties gehouden over Ruby én Rails bij onze werkgever. Het publiek bestond vooral uit collega java ontwikkelaars en enkele externe ontwikkelaars.
Het is verschrikkelijk moeilijk om binnen twee keer drie kwartier te blijven en dat is dan ook in beiden sessies helemaal niet gelukt. Er is te veel moois om te laten zien in zowel Ruby als Rails. Ondanks de rommelige en veel te lange representaties waren de reacties positief.
Voor iedereen die er niet bij kon zijn, niet op de hoogte of niet uitgenodigd was, of, zoals velen die de Amsterdam sessie bijwoonde, het niet helemaal hebben kunnen beleven; ter inzage de bestanden:
RoR Presentatie bestanden en meer!
Hier zijn onze spiekbriefjes, code en nog wat links te vinden. Op en aanmerkingen worden op prijs gesteld.
Geplaatst in ruby, ruby on rails | 1 reactie
Geplaatst door Michiel de Mare
zo, 12 feb 2006 06:52:00 GMT
Ik ben nu bezig met het voorbereiden van een presentatie over Ruby on Rails die Remco en ik volgende week zullen geven (meer informatie later). Een van mijn onderwerpen is
method_missing, en zo kwam ik op het idee voor deze implementatie:
class Object
def method_missing(name, *args)
puts "Nog geen methode voor #{self.class} #{name}."
puts "Voer er nu s.v.p. een in:"
m = []
puts m << "def #{name}(*args, &proc)"
m << gets.chomp until m.last =~ /^end$/
eval m.join(';')
self.send(name,*args)
end
end
irb(main):056:0> "JAVA".zuul
Nog geen methode voor String zuul.
Voer er nu s.v.p. een in:
def zuul(*args, &proc)
chop.reverse.chop.succ
end
=> "VB"
Geplaatst in ruby | geen reacties
Geplaatst door Danny Lagrouw
zo, 05 feb 2006 22:57:00 GMT
Dit weekend sprak ik iemand die informaticavakken doceert aan een redelijk grote HBO-instelling. Hij vertelde me dat eerstejaars studenten daar leren programmeren in… PHP. Nu heb ik niets tegen PHP: je bent er snel mee op weg, en zeker als je maar een of twee stukjes programmatuur in je website nodig hebt is het haast overkill om geen PHP te gebruiken. Maar om mensen die voor het eerst officieel kennismaken met programmeren, mensen die met een schone lei zouden moeten beginnen en de beginselen van de edele programmeerkunst goed onderwezen moeten krijgen als basis voor alles wat ze later aan talen tegen kunnen komen—om die mensen te laten beginnen met PHP, dat lijkt me helemaal niet onderwijskundig verantwoord. Mijn voornaamste bezwaar is dat de taal geen structuur afdwingt, zelfs uitnodigt tot spaghettiprogrammeren. Eigenlijk hetzelfde argument dat ik hoorde tegen BASIC toen ik voor het eerst officieel leerde programmeren (in Pascal). (In de V.S. is de situatie trouwens al niet veel beter).
De bevriende docent gaf me ten dele gelijk, maar verdedigde zich door te zeggen dat hetzelfde vak ook door Bestuurlijke Informatiekundestudenten gevolgd wordt, die later waarschijnlijk toch niet meer gaan programmeren (waarschijnlijk worden dat de mensen die tegen jou zeggen: “Zo moeilijk is dat toch niet? In PHP doe ik dat binnen vijf minuten…”). Uiteraard heb ik uitvoerig reclame gemaakt voor Ruby en Rails en hem een boek geleend, overeenkomstig de ondertitel van deze blogportal. Maar ik moet eerlijk zeggen dat ik niet weet of Ruby wel een geschikte taal is voor een eerste officiele kennismaking met programmeren. Is het niet beter om te beginnen met een taal die je meer beperkt in je mogelijkheden? Een taal waarin je alle variabelen netjes moet declareren, waarin geen goto bestaat en geen break? Misschien niet eens een object-georiënteerde taal, of geen hogere taal, of geen algemeen bekende programmeertaal. Aan de andere kant biedt Ruby het voordeel dat er elementen uit verschillende soorten programmeertalen in samenkomen. Misschien was Pascal zo gek nog niet…
Geplaatst in onderwijs, ruby on rails, ruby | geen reacties
Geplaatst door Michiel de Mare
wo, 01 feb 2006 09:32:00 GMT
Ruby On Rails heeft inderdaad geen goede helemaal geen i18n ondersteuning, maar Java propertyfiles hebben ook zo hun problemen. Zo zijn ze bijzonder inflexibel. Ze hebben rudimentaire ondersteuning voor variabele substitutie (bv. "{0} moet ingevuld zijn."). Maar dat is lang niet genoeg.
Hoe pak je bijvoorbeeld de volgende problemen aan met propertyfiles?
- Je score is {0} (gradatie in woorden)
- Je ziet {0} goblin (meervoud of enkelvoud)
- Hans was hier {0} geleden (hoeveelheid tijd in woorden).
Bij mijn eigen projectje gebruik ik blocks.
LAST_POST =
{:en => "%s replied %s ago",
:nl => "%s antwoordde %s geleden",
:es => "%s contestó hace %s" }
def last_post(name, time)
lambda do|lang|
stime = time_ago(time)[lang]
sprintf(LAST_POST[lang], name, stime)
end
end
puts last_post('Hans', Time.now - 100)[:en]
Iets meer werk om te schrijven, maar oneindig veel flexibeler. Bovendien gebruikt deze methode lazy evaluation zodat je model niet meteen hoeft te weten welke taal je gebruikt. Dat kun je aan je view-laag overlaten.
Geplaatst in ruby on rails, ruby | geen reacties
Geplaatst door Danny Lagrouw
zo, 29 jan 2006 03:14:00 GMT
Is het internationalisering of internationalisatie? I18N dan maar, dan weet iedereen wat ik bedoel. Een onderwerp dat helaas lijkt te zijn ‘vergeten’ in Ruby on Rails—terwijl de bedenker nota bene uit Denemarken afkomstig is.
Ongetwijfeld zal het niet lang duren voordat deze leemte kan worden opgevuld met een los ontwikkelde plugin of module. En dat is nu juist jammer; een standaard oplossing, meegedownload met Rails, had kunnen voorkomen dat we in de toekomst in verschillende projecten rekening moeten houden met verschillende oplossingen, of erger nog, zelfgeschreven oplossingen.
Een voorbeeld van zo’n
I18N-oplossing voor Rails is
Globalize. Globalize is een plugin voor Rails. Je kunt er vertalingen van teksten mee opslaan in de database, en deze vertalingen transparant weer ophalen, bijvoorbeeld:
Locale.set("en-US")
prod = Product.find(1)
prod.name -> "Meatballs"
Locale.set("nl-NL")
prod = Product.find(1)
prod.name -> "Gehaktballen"
Een nadeel hiervan lijkt me dat de vertalingen sterk gekoppeld worden aan database records. Als er nog een ander product is met de naam ‘Meatballs’, dan staat niets je in de weg om daar een andere vertaling bij op te slaan. En zelfs als je dezelfde vertaling gebruikt, dan zal die vertaling dus dubbel worden opgeslagen.
Deze oplossing lijkt me dan ook het meest geschikt voor het vertalen van database-inhoud. Voor het vertalen van statische tekst zie ik meer in de Java-oplossing, waar vertalingen worden opgeslagen in resource bundles (tekstbestanden). Je vraagt een vertaling op aan de hand van een sleutelwaarde, met een method call of (in een
JSP) met een tag. Dat laatste zie ik in een Rails rhtml-bestand dan weer heel mooi voor me:
<%= "label.enter.productname".translate %>
(waarbij voor ‘translate’ nog een passend afgekort alias gebruikt kan worden).
Geplaatst in ruby on rails, ruby | 2 reacties
