Geplaatst door Michiel de Mare
do, 31 aug 2006 13:22:00 GMT
Eén van de leuke uitbreidingen van Rails op Ruby is de to_proc methode in de Symbol class. Op een plek waar Ruby een Proc verwacht (na een ampersand bijvoorbeeld) maar een ander object tegenkomt, roept Ruby de to_proc methode van dat object aan, die, indien aanwezig, een proc teruggeeft die gebruikt kan worden. Voorbeeld: ['hallo','lezertjes'].map &:upcase geeft ['HALLO','LEZERTJES'].
Ook argumenten worden ondersteund. Als je map bijvoorbeeld aanroept op een Hash worden er twee argumenten (key en value) meegegeven. Om de key door de value te delen doe je dit: {33 => 11,39 => 3}.map &:div, wat geeft [3,13].
Er is alleen één probleem. Ruby maakt geen onderscheid tussen arrays en meerdere argumenten. De to_proc implementatie gaat uit van meerdere argumenten; probeer je een array mee te geven dan gaat het mis: [[1,2,3],[4,5,6],[7,8,9]].map &:first
Je verwacht: [1,4,7], maar je krijgt NoMethodError: undefined method `first' for 1:Fixnum
Ruby 2 gaat als het goed is onderscheid maken tussen arrays en meerdere argumenten. Tot die tijd moeten we de blocks maar even uitschrijven…
Update:
Symbol is natuurlijk niet de enige class die hiervoor te misbruiken is. Hier een variant voor de Regexp:
class Regexp;
def to_proc; Proc.new {|a|
a.send source.to_sym
};end;
end
[[1,2],[3,4]].map &/first/
Geplaatst in ruby, ruby on rails | geen reacties
Geplaatst door Michiel de Mare
di, 29 aug 2006 03:54:00 GMT
Ik ben op een vreemde eigenschap in Ruby gestuit terwijl ik een loop counter probeerde te schrijven die niet geïnitialiseerd hoefde te worden.
i = 1 + (i || -1)
Het idee was dat de eerste keer de counter op 1 + -1 (==0) wordt gezet, en dat hij daarna met één verhoogd wordt. Maar toen bedacht ik dat dit niet werkt omdat de rechterkant eerst geëvalueerd wordt, en daarin i ongedefineerd is. Toch bleek dit te werken! bar geeft een foutmelding, maar bar = bar is wel geldig!
Vreemd, nietwaar?
Uiteindelijk bleek deze constructie niet te werken omdat hij in een block stond, zodat alle lokale variabelen uit scope raken aan het eind van een block.
Geplaatst in ruby | 3 reacties
Geplaatst door Remco van 't Veer
ma, 28 aug 2006 07:36:00 GMT
Zojuist heb ik de dutchify beschikbaar gemaakt om het schrijven van nederlandstalige website gemakkelijker te maken.
Geplaatst in ruby on rails
Geplaatst door Michiel de Mare
zo, 27 aug 2006 21:57:00 GMT
Stel dat je een unittest wil schrijven voor een module die data gebruikt. Je wilt zelf verschillende randvoorwaarden testen zonder de systeemtijd aan te passen. Hoe doe je dat? In Java moet je je gehele code-base doorspitten naar vormen van new Date() en Calendar.getInstance() en die vervangen door een of andere DateFactory, via welke je unittest de datum kan manipuleren.
In Ruby doe je dit:
def setup
class <<Time
attr_accessor :now
end
end
def teardown
class <<Time
alias_method :now, :new
end
end
def test_date
Time.now = CHRISTMAS_1997
assert MyClass.new.turkey?
Time.now = EC_FINAL_1988
assert !MyClass.new.turkey?
end
Geplaatst in ruby | geen reacties
Geplaatst door Danny Lagrouw
ma, 21 aug 2006 21:52:00 GMT
In mijn jeugd kende ik twee timmermannen, die elk een eigen manier van werken hadden. De eerste, mijn opa, was zo iemand wiens handen konden maken wat hij zag. Kasten, tafels, trapjes, hij kon alles. Je gaf hem een beschrijving van wat je wilde hebben, hij kreeg een glans in zijn ogen, en ging aan het werk. Hij had een enorme verzameling bij elkaar verzameld gereedschap, waar hij echter meestal maar een klein deel van gebruikte. Hij ging zo op in zijn werk, dat hij soms de moeite niet nam om het gereedschap te gaan halen dat hij nodig had; met wat hij toevallig in zijn handen had ging het vaak even goed. Tijdens het werk had hij altijd voor ogen hoe het het wilde hebben. En na enige tijd liet hij je vol trots het eindresultaat zien. Hij had plezier in zijn werk.
De tweede timmerman die ik kende was mijn oom. Mijn oom had een aantal jaar lang een timmercursus gevolgd, maar vond dat hij eigenlijk nog altijd niet genoeg geleerd had om volwaardige producten af te kunnen leveren. Als je hem vroeg om iets te maken, wilde hij precies weten hoe het eruit moest zien, wat de maten moesten zijn, welk materiaal hij moest gebruiken. Dan kreeg hij een vermoeide blik in zijn ogen, en ging aan het werk. Ook hij had veel gereedschap, nieuw gekocht van het beste merk. Als hij met zijn klus bezig was, lette hij er altijd op het juiste gereedschap te gebruiken, zoals hij het had geleerd. Hij verachtte mijn opa, omdat hij hem ooit een schroevedraaier als beitel had zien gebruiken. In zijn ogen was er voor elke klus een gereedschap dat het best geschikt was. Tijdens het werk had hij altijd het juiste gereedschap voor ogen. Het eindresultaat haalde hij niet vaak. Ik heb hem nooit blij zien kijken als hij bezig was.
Wanneer is PHP “the best tool for the job”, en wanneer is Ruby dat? Volgens mij is het beste gereedschap voor een klus datgene wat de programmeur in kwestie op dat moment het beste gereedschap vindt. Er is in principe geen (in Platonische zin) ‘absoluut’ beste gereedschap aan te wijzen voor een willekeurige klus. Als ik klaag dat ik geen Ruby kan gebruiken voor kleine webformuliertjes, dan is dat niet omdat ik koste wat kost Ruby wil gebruiken—maar om de klus te klaren grijpen mijn handen naar het gereedschap dat op dat moment het dichtstbij ligt, dat het meest vertrouwd aanvoelt, waarmee ik het snelst klaar kan zijn. En op dit moment is de programmeertaal waarin een programma-idee in mijn gedachten zo ongeveer 1 op 1 overeenkomt met een uitwerking op de computer, (naast Java), Ruby. Hoe kan iemand dan nog beweren dat ik beter PHP kan gebruiken? For any job?
Geplaatst in ruby, opinie | 2 reacties
Geplaatst door Danny Lagrouw
vr, 11 aug 2006 03:31:00 GMT
Bij alle opschudding over een flink lek in Ruby on Rails, valt op dat de eigenlijke opschudding vooral te maken heeft met de houding die het Rails core team innam ten aanzien van het lek. Aanvankelijk werd alleen een nieuwe upgrade (1.1.5) gepubliceerd, met de mededeling dat details over het lek pas na een tijdje openbaar zouden worden gemaakt. Dit om mensen de tijd te geven om de upgrade te installeren, voordat misbruik gemaakt zou kunnen worden van de informatie over het lek. Deze houding heeft zich echter nogal tegen het core team gekeerd. Ten eerste bleek een dag later dat Rails 1.0 (en eerder) en 1.1.3 geen last hadden van het lek; gebruikers van deze versies hadden zich dus ten onrechte zorgen gemaakt en onnodig veel tijd besteed om te upgraden naar 1.1.5. Bovendien bleek dat met 1.1.5 nog niet het hele probleem was opgelost, waardoor 1.1.6 snel volgde. De 1.0 en 1.1.3 gebruikers waren door de onnodige upgrade dus feitelijk in een minder veilige situatie terechtgekomen.
De meningen in de community zijn verdeeld: kun je beter zo snel mogelijk alle details openbaar maken (waardoor het probleem sneller want door meer mensen kan worden opgelost, maar hackers ook meer kans krijgen)—of beter eerst een patch of upgrade uitbrengen en daarna ‘full disclosure’ geven? De gang van zaken in de afgelopen dagen lijkt voor het eerste te pleiten…
(Overigens draait RubyEnRails.nl, dankzij Typo, nog met een behoorlijk antieke versie van Rails, en lijkt dus veilig. In het diepste geheim wordt momenteel gewerkt aan een eigen server voor onze site—meer hierover later).
Geplaatst in ruby on rails | 1 reactie
Geplaatst door Remco van 't Veer
wo, 02 aug 2006 02:39:06 GMT
Er is wat herrie over de populariteit van RailsConf Europe. In tegenstelling tot de “originele” conferentie zijn de kaarten, na weken, nog niet uitverkocht.
De grootste klacht is dat het te duur is. London is een veel te dure stad voor dit soort dingen. Daarbij komt dat er in de VS veel meer mensen professioneel met Rails bezig zijn en er dus vanuit deze bedrijven meer budget is om deel te nemen.
Dat laatste is wel een beetje zorgelijk. Europa gedraagt zich vaak een beetje terughoudend als het om nieuwe ontwikkelingen gaat. Of het om een gebrek aan flexibiliteit gaat of botweg chaufinisme weet ik niet. Ik geloof dat er ook in europa een hoop geld te verdienen valt met Ruby on Rails en dat dit soort evenementen belangrijk zijn voor de ontwikkeling van dit platform. Europa heeft veel oplossingen, DHH zelf en andere core ontwikkelaars, en problemen, meertaligheid en unicode ondersteuning, te bieden.
Dus neem je opleidingsbudget nog een keer onder de loep of probeer je werkgever nog een keer duidelijk te maken dat de toekomst van het bedrijf op het spel staat! In september hang ik daar in iedergeval rond met m’n powerbook onder m’n arm. Zie je daar?
Geplaatst in ruby on rails, events | 6 reacties
Geplaatst door Remco van 't Veer
do, 20 jul 2006 05:14:00 GMT
De jongens van Buildless (zie ook pinupgeek.com) hebben een workshop Ruby on Rails met David Black georganieerd voor 18 september in het Amsterdamse hotel Arena. David Black is een bekende naam in de Ruby gemeenschap en heeft het pas gepubliceerde Ruby for Rails geschreven.
Dus als je na RailsConf Europe nog meer live input wilt genieten, geef je dan snel op! Early bird loopt tot 30 juli en scheelt 50 euro.
Geplaatst in ruby on rails, onderwijs, events | geen reacties
Geplaatst door Danny Lagrouw
di, 11 jul 2006 10:50:00 GMT
Ondanks hun enthousiasme voor Ruby en Rails grijpen mensen nog vaak naar
PHP als ze een “echte” website maken. Kijk bijvoorbeeld maar eens naar het aantal Ruby-blogs en Ruby-forums dat met
PHP wordt opgezet. Dat leidt dan tot enige hoon van bezoekende Rubyisten, maar op zich is het wel begrijpelijk.
- Veel mensen hebben meer ervaring met PHP, en kunnen daar dus sneller mee overweg.
- De “kant-en-klare” software die in PHP verkrijgbaar is (zoals blogging software, cms-en e.d.) heeft jaren voorsprong op hun Ruby/Rails tegenhangers; en dat merk je in stabiliteit, gebruiksgemak, hoeveelheid features, documentatie en ondersteuning.
- Door die jaren voorsprong is er ook meer keuze in PHP-land voor dat soort software.
- Webhosting… probeer maar eens een Rails site in Nederland te laten hosten. En ook de hosting in het buitenland kent zo zijn problemen. Niet voor niets las ik in een verslag van RailsConf, “Shared hosting + Rails == Suck; Avoid if you can; Rails is ‘a bit of a pig’ compared to the average PHP site”.
Een vierde reden (er zijn er vast nog meer) ontdekte ik toen ik een inschrijfformulier online wilde zetten voor het volgende Profict-event (dit keer helaas geen Ruby, maar Java en Ajax). Het inschrijfformulier verstuurt een mail naar mij, met de inschrijfgegevens. Bovendien worden de gegevens via een http-request op de achtergrond doorgegeven aan een event-organisatie-systeem dat ik in Rails heb gebouwd (achteraf hoorde ik van Remco dat zo’n systeem in vijfvoud is gebouwd tijdens de RAD-race, maar gelukkig: Reuse is vastly overrated). Welnu, hoe maak je zo’n mailformulier, bestaande uit welgeteld één script om de gegevens te mailen en door te sturen? Juist, in PHP. Even afgezien van het feit dat de betreffende provider geen Ruby heeft geïnstalleerd: ik zou eigenlijk met Ruby hetzelfde willen kunnen doen als met PHP. Dus een .rhtml bestand dat de form parameters binnenkrijgt, daar een mail van bakt, en een nette “bedankt en tot ziens”-pagina terugstuurt naar de bezoeker.
Lees verder...
Geplaatst in ruby, ruby on rails | 8 reacties
Geplaatst door Michiel de Mare
zo, 25 jun 2006 12:20:00 GMT
RailsConf 2006 is achter de rug. Het is een geweldige ervaring om zoveel mensen te spreken die op zoveel manieren bezig zijn met Rails. Er komt ook een Europese conferentie aan in Londen en in mei 2007 komt de tweede editie van RailsConf in Portland, Oregon.
Naast de vreselijke nederlaag tegen Portugal heb ik een interessante sessie gezien over metaprogramming – welke technieken heb je tot je beschikking, hoe werkt Rails achter de schermen, etc. Erg interessant, en het wordt tijd voor een boek over dit onderwerp.
Tenslotte nog wat quotes.
Mike Clarke:”I have been Java-free for 15 months and 17 days.” (big applause)
DHH:”Decisions are BAD!”
Anonymous:”It’s been a long time since I programmed in C++ ... But not long enough!”
Geplaatst in ruby on rails | 1 reactie
