Geplaatst door Remco van 't Veer
wo, 20 dec 2006 10:30:00 GMT
De JRuby bijeenkomst die gisteren door Finalist georganiseerd is in Rotterdam was een groot succes. Een goede opkomst van tegen de 50 man en natuurlijk super helden Charles en Thomas.
Charles heeft een introductie Ruby gegeven en daarna JRuby gedemonstreerd met jirb (zie ook de webstart versie van Thomas). Een beetje Java Swing in JRuby, windowtje maken met een knop en een label erop. Daarna heeft hij een kleine Swing DSL laten zien; swingbuilder. Vooral die laatste was erg leuk omdat dat goed laat zien waarom het goed is om Ruby te hebben op het Java Platform. Lompe stukken Java code kunnen zo gemakkelijk ver-DSL-t worden.
Na een korte pauze heeft Thomas een Rails inleiding/demo gegeven op JRuby. Daarna heeft Charles nog het aanroepen van EJB’s laten zien en een development build van Netbeans laten zien waar al wat Ruby en Rails support in zit.
Erg leuke avond, hopelijk komt er binnenkort weer een kans om een super ster te ontmoeten!
Geplaatst in ruby, ruby on rails, events, java | 1 reactie
Geplaatst door Danny Lagrouw
do, 07 dec 2006 20:19:00 GMT
In het enterprise-verantwoorde tijdschrift Informatie (november 2006) is een inleidend artikel over Ruby en Ruby on Rails geplaatst. Een mooie gelegenheid om RoR onder de aandacht te brengen van een nog groter publiek. Het artikel is hier als pdf (1MB) te downloaden; zie verder ook de site van Informatie.
P.S. Jaja, het staat natuurlijk vol met fouten die alleen de echte RoR-kenners er uit halen. Kom maar op met dat commentaar!
Geplaatst in ruby, ruby on rails, nieuws | 3 reacties
Geplaatst door Michiel de Mare
wo, 15 nov 2006 03:37:00 GMT
Op 19 december zal Charles Nutter bij Finalist in Rotterdam een lezing geven over zijn werk aan JRuby. Toegang is gratis.
Je kunt er hier meer over lezen, en je alvast opgeven. Wacht niet te lang, er is een beperkt aantal plaatsen.
Hopelijk zien we jullie daar!
Update: fix link
Geplaatst in ruby, events | 2 reacties
Geplaatst door Danny Lagrouw
ma, 16 okt 2006 10:04:00 GMT
LogicaCMG organiseert een aantal gratis toegankelijke sessies onder de noemer Guru4Pro. Op donderdagavond 2 november a.s. zal guru Chad Fowler een sessie verzorgen over innovaties in softwareontwikkeling. Hij zal in deze Guru4Pro ingaan op de kerninnovaties binnen het Rails framework (en de hype daarachter), met de bedoeling om de geleerde lessen naar andere omgevingen, zoals Java/J2EE, te vertalen die daar hun voordeel mee kunnen doen.
Chad Fowler is o.a. auteur van Rails Recipes en co-auteur van de Pickaxe, is organisator van RubyConf en RailsConf, en geeft regelmatig workshops over Ruby on Rails.
Deelname aan deze avond (inclusief diner en meet&greet met Chad) is geheel gratis. Voor meer informatie en aanmelding: www.logicacmg.com/nl/guru4pro.
Geplaatst in ruby, ruby on rails, events | 4 reacties
Geplaatst door Remco van 't Veer
do, 12 okt 2006 00:12:00 GMT
Laatst sprak ik iemand die rails gebruikt om prototypes te bouwen voor J2EE web applicaties omdat het zo lekker snel werkt. Het uiteindelijke project wordt uitgewerkt in J2EE. Ten opzichte van J2EE is er met rails erg snel iets in elkaar te zetten maar wat doe je als je een prototype nodig hebt voor een rails site?
Je kan natuurlijk gewoon beginnen met rails fancy_shit en los gaan. Vroeg in de ontwerp fase van een project vind ik dat een beetje overkill, als je alleen maar een beetje wilt goochelen met een paar objectjes om gevoel te krijgen voor het probleem wat je probeert op te lossen.
versus 
Gelukkig is er iets veel beters dan rails voor dit soort dingen!
Lees verder...
Geplaatst in ruby | 3 reacties
Geplaatst door Michiel de Mare
do, 07 sep 2006 05:07:00 GMT
Er zijn een paar dingen die ik regelmatig tegenkom in Ruby, en waarvan ik denk dat het makkelijker kan. Dit bijvoorbeeld:
x = foo(y)
return x if x
Wat ik liever zou zeggen is:
only_return_if foo(y)
Een andere is dit:
x = {}
arr.each {|o| x[o] = foo(o) }
Hier zou ik liever zeggen:
arr.make_hash {|o| [o, foo(o)] }
Of de tegenhanger:
x = {}
arr.each {|o| x[o.foo] = o }
Dat schrijf ik liever als:
arr.key_hash &:foo
Voor het bovenste probleem heb ik geen oplossing – de andere kan ik zelf wel aan array toevoegen, maar ik gebruik veel liever een oplossing zonder ‘monkey patching’.
8 september: Update
Het kan! Niet met mijn syntax, maar wel iets vergelijkbaars:
def iff(a)
yield a if a
end
def foo(a)
iff(a) {|x|return x}
'het mocht niet zo zijn'
end
foo('ja!') => 'ja'
foo(nil) => 'het mocht niet zo zijn'
Geplaatst in ruby | 5 reacties
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 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
