Geplaatst door Remco van 't Veer vr, 27 jun 2008 07:00:00 GMT
Behoefte je horizon te verbreden? De veel besproken MagLev VM in actie zien? Meer weten over het legendarische Seaside framework?
Eind augustus organiseert de ESUG de 16th International Smalltalk Joint Conference 2008 bij het CWI in Amsterdam.
Lees verder...Geplaatst door Remco van 't Veer wo, 11 jun 2008 14:23:00 GMT
Na maanden van bier drinken in een donkere rumoerige kroeg wordt het tijd om eens iets met computer te gaan doen (en misschien een beetje Ruby) tijdens ons maandelijkse avondje.
Ward heeft aangegeven dat we met z’n allen welkom zijn op het kantoor van z’n werkgever:
Het gerucht is dat er bier koud staat! Dus.. Neem een laptop en mooie ideëen mee!
Geplaatst door Michiel de Mare ma, 26 mei 2008 20:11:33 GMT
Een paar leuke ruby truukjes
Er zaten een paar tussen die ik nog niet kende, maar die wel erg handig zijn (2, 4, 18).
Geplaatst door Michiel de Mare wo, 05 maa 2008 15:51:00 GMT
Ik heb net een artikel in het Engels gepost dat ik niet onmiddellijk van plan ben om te vertalen, maar via deze link kun je de code niet alleen bekijken, maar ook uitvoeren en aanpassen!
Very cool! Dat gaan we hier vaker gebruiken.
Geplaatst door Michiel de Mare wo, 05 maa 2008 06:24:00 GMT
What a sudden interest in avoiding NoMethodErrors on nil lately! I’ve just thought of another method. (Remember, you can solve any problem by adding a layer of indirection.)
Say you have Remco’s canonical example: person.name.upcase
Both person and person.name may be nil. So we usually write: person && person.name && person.name.upcase.
rrss? I’ve introduced
it last month. It stands for “returns result, same self”. Its definition is beyond trivial:
class Object
def rrss
yield self
end
end
rrss we can rewrite the original as:
person.rrss {|p| p.name}.rrss {|n| n.upcase}
Or with to_proc notation:
person.rrss(&:name).rrss(&:upcase).
We still need to check for nil though:
person.rrss {|p| p && p.name}.
rrss {|n| n && n.upcase}
Doesn’t this last bit look like it’s in need of a bit of refactoring? Its lack of DRY-ness jumps right out of the page.
Lees verder...Geplaatst door Remco van 't Veer vr, 29 feb 2008 07:40:00 GMT
Warning: only apply the following under parental guidance!
We know the whiny nil, as applied in Rails, but what about an obedient nil:
class NilClass
def method_missing(*args)
nil
end
end
No more monkeying like:
person && person.name && person.name.upcase
Not DRY at all! Let’s use the obedient nil instead:
person.name.upcase
This concludes our last daily method. Ode to Michiel for providing a vast amount of nice tricks!
Geplaatst door Remco van 't Veer vr, 29 feb 2008 07:25:00 GMT
Waarschuwing: alleen gebruiken onder toezicht van een meerderjarige!
We kennen de whiny nil, zoals toegepast in Rails, maar wat nou whiny?! Bij deze de obedient nil:
class NilClass
def method_missing(*args)
nil
end
end
Geen geklooi meer:
person && person.name && person.name.upcase
Niet echt DRY! Nu met de obedient nil:
person.name.upcase
Het is alweer de laatste dag methode. Ode aan Michiel voor de hoeveelheid gave trucs die hij uit z’n hoge hoed heeft kunnen trekken!
Geplaatst door Michiel de Mare wo, 27 feb 2008 08:03:00 GMT
Do you know what I like so much about relational databases? And what I really miss in object-models? That databases make it so effortless to index data.
Imagine, you’ve got a huge pile of data, unordered, continually changing, but because your database keeps a few indexes, you can access any item you wish within a few milliseconds.
Wouldn’t it be fun if you could do that in Ruby? Especially the effortless part? It happens regularly that I’ve got an array with hundreds of items in which I have to search. That quicky gets slow, so I create a few hashes that I use as indexes. But what a difference with a real database!
Let make a first step in the right direction, and implement the make_index method.
module Enumerable
def make_index(*names)
Struct.new(*names).new(*names.map{|n| group_by(&n)})
end
end
index = User.find(:all).make_index(:login, :id, :nickname)
index.login['mdemare'] => [<#User ...>]
index.nickname['Michiel'] => [<#User ...>]
I admit, not a huge improvement yet. But we’re getting there. For another time, indexes on more than one attribute, unique indexes and indexing attributes with a natural order. (index.created_at > Time.now.at_midnight)
Geplaatst door Michiel de Mare wo, 27 feb 2008 08:00:00 GMT
Weet je wat ik zo geweldig aan databases vind? En wat ik zo mis aan object-modellen? Dat is dat databases het zo makkelijk maken om data te indexeren.
Stel je voor, je hebt een ongelooflijke bak data, ongeordend, continue veranderend, maar omdat je database een paar indexen bijhoudt kun je toch binnen milliseconden bij elk item dat je wilt.
Zou het niet leuk zijn als dat in Ruby ook kon? Het overkomt me namelijk best vaak dat ik een lijst met honderden items waarin ik wil zoeken. En er overheen itereren wordt al heel snel traag. Dus voor dat ik het weet heb ik overal losse hashes liggen die ik als index gebruik. Maar wat een verschil met een database.
Laten we vandaag een eerste stap in de goede richting zetten met de make_index methode.
module Enumerable
def make_index(*names)
Struct.new(*names).new(*names.map{|n| group_by(&n)})
end
end
index = User.find(:all).make_index(:login, :id, :nickname)
index.login['mdemare'] => [<#User ...>]
index.nickname['Michiel'] => [<#User ...>]
Voor een andere keer: indices op meer dan één attribuut, en het indexeren van attributen met een natuurlijke ordening.
Geplaatst door Michiel de Mare di, 26 feb 2008 08:00:00 GMT
Searching in arrays is pretty slow. Better use a hash.
But if the array is already sorted, you can use a binary search, which works by dividing the array in two and searching in the left orthe right part, until there’s only one element left.
class Array
def bsearch(k)
x,y = -1,size
while y != x + 1 do
m = (x + y) / 2
if self[m] <= k
x = m
else
y = m
end
end
x >= 0 && self[x] == k && x
end
end