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 Danny Lagrouw
ma, 20 feb 2006 23:23:00 GMT
Eind vorige week wees Remco me op Campfire, een (Rails) site waar je met vrienden en collega’s gezamenlijk kunt chatten. De chatrooms blijven bestaan, ook als alle deelnemers uitloggen. Als je later terugkomt in dezelfde chatroom kun je nalezen wat er in je afwezigheid is gezegd. Een mooi concept. Campfire is zo slim geweest om in de gratis versie het aantal deelnemers per chatroom te beperken tot vier; dat is al snel te weinig. Maar hoe moeilijk is het eigenlijk om zelf een kampvuurtje te stoken? Dat blijkt best wel mee te vallen…
(lees verder)
Geplaatst in ruby on rails, ajax
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 Danny Lagrouw
wo, 08 feb 2006 22:47:00 GMT
Wat een teleurstelling… RailsConf is al uitverkocht voordat ik me kon aanmelden. 400 plaatsen is ook niet al te veel. Er zit maar één ding op: een Nederlandse of Europese (Ruby en) RailsConf, nog dit jaar.
Geplaatst in ruby on rails, events | 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
