Team Size

Team Size Can Be the Key to a Successful Project

3-5, 5-7 are the "magic" numbers.
I think 4-6 (2, 3 pairs) is more appropiate.

Unit-Test and Mocking

1st. ObjectMentor: StopMockingMe (Mocks by Hand vs. Dynamic Mocks)
2nd. ThoughtWorks: Mocks are Evil

I think that the notion of OO is not really well understood: in an OO-world, we have objects,
and messages. Object A sends the message MSG to object B.

“...things often go wrong where one part of a system communicates with another (e.g. business logic connects to a database). The mocked out functions are usually called correctly, but something else is going wrong (e.g. permissions have not been set on the database).” (from comments)

I have the impression that it is not cleared what is it tested, what Unit are we testing now?
Are we testing the object A who sends a message to B, or are we testing B, which is a DB access point? In an OO world, A has no ideea hat implementation has B, and if a DB is behind. Probably,
the right question is: we have not defined how A will react, if B does not respond to the message,
or if it throws an exception.

“Why we should use mocks when we could test for free all underlying layers?” (other developers conversations).
Unit-Test !? We are testing an object, who works with several interfaces... (see PicoContainer-GoodCitizen).

And now from the original post, the story about the Lamp and the Light:

Lets take classic object Lamp.

public class Lamp {
private boolean on;
public void switchOn() {
setOn(true);
}
public boolean isOn() {
return on;
}
private void setOn(boolean on) {
this.on = on;
}
}

Might be I am missing something here. How can we make sure switchingOn behavior worked correctly without verifying the state (on/off) of Lamp?

Isn't this a philosophical question?
Is it there really a light if you are not there to see it? (I think there is an old chinese saying with a falling tree in a forrest)
Do we have light if the Lamp's button says that the lamp is on?

Maybe a better approach would be:

testLampObserverSeesLight() {
lamp.Attach(observer)
lamp.SwitchOn()
Assert.IsTrue(observer.SeesLight());
}

( I still think that test_observer_sees_light_when_lamp_switch_on() is a better name :D)

Bottom-End: Unit-Tests are a base for your development. If they are incomplete: is your fault.
If you test Setters/Getters is your fault. If you want to test the DB in the BussinessLogic layer: is your fault.

Conveying intent in tests

here

what is more readable:

testValidateAddressFailsWithMissingStreetName()
very long "german"-kind-of function name, or:
test_validate_address_fails_with_missing_street_name()

I found the 2nd more readable, i.e. it documents better the intent of the function validate(). Is it right to have a coding style for UnitTests (snake-style) and another style for coding !?

Matz said that for him the 2nd coding style is easier to read. I've got used with camel/Pascal case, but for the cases mentioned above, it is really a pain (in the eye).

I read the whole sentence, than I have to re-read it, to impregnate my brain with its meaning. Maybe we should reconsider Word_Separators.

On the other hand, if the name is too big, is probably a CodeSmell: the function is doing too much, the object knows too much. (DataGridPreferredColumnWidthTypeConverter !?) Maybe another namespace separation is needed?




Rake and Rant

Jim Weirich (the author) tutorial
rakefile.rdoc
Martin Fowler's article
Ruby for Java builds

Rant (Stefan Lang)

The Free Lunch is Over

Why the programming needs/will shift to concurrency.

I found the same concern in Martin Fowler and Bertrand Meyer's writings.
A better concurency model (for our brains) is needed.

Ruby Gem

from here:

problem:

I have a class Foo which has a number of heavy, CPU intensive, number
crunching methods that take parameters.

class Foo
attr_reader :x, :y, ...

def calc1(a,b,c)
...# complicated, time-consuming calculation...
end
def calc2(a,b)
...# complicated, time-consuming calculation...
end
...
end

Foo is immutable. If a client calls a method more than once using the
same set of parameters, the same result will be calculated and
returned.

To avoid the work of recalculating a result if a client calls a method
more than once with the same set of parameters, I revised Foo to cache
results in a hash for each method for each set of parameters. The
keys in the hashes are arrays of parameters.

class Foo
def calc1(a,b,c)
param_array = [a,b,c]
@cache_calc1 ||= {}
return @cache_calc1[param_array] if @cache_calc1[param_array]

ans = ... #same complicated, time-consuming calculation...
@cache_calc1[param_array] = ans
end

def calc2(a,b)
param_array = [a,b]
@cache_calc2 ||= {}
return @cache_calc2[param_array] if @cache_calc2[param_array]

ans = ... #same complicated, time-consuming calculation...
@cache_calc2[param_array] = ans
end
end

This works great -- calculations for a given set of parameters on
each method are now done only once. However, the code seems rote,
repetitive and intrusive to the original methods.

Is there a way to do this in Ruby in a more declarative, more DRY way?

Solution:

> You could check out Daniel Berger's memoize (based on Nobu Nokada's
> original I think) on RAA (http://raa.ruby-lang.org/project/memoize).

Thank you and wowser! memoize seems to do just what I'd been looking
to do. A handful of lines. I can see it works.

#my test code
f = Foo.new
f.memoize(:calc1)
f.memoize(:calc2)
f.calc1(1,2,3)
f.calc1(1,2,3) #yep its working
f.calc1(7,8,9) #yep its working

If I can ask a Ruby 101 question about it... Isn't "cache" in the
module (pasted below in its entirety it is so short) only a local
variable? Why does is retain state? How can one, for example, access
the cache to see the state of the cache?

Thanks!

--Brian

module Memoize
MEMOIZE_VERSION = "1.0.0"
def memoize(name)
meth = method(name)
cache = {}
(class << self; self; end).class_eval do
define_method(name) do |*args|
cache[args] ||= meth.call(*args)
end
end
end
end


Delicious.

Distributed Revision Control

darcs and svk (based on subversion).
I didn't look closely into Gnu arch.

Why I like Ruby

Because the Collections are smart.
Here is how Martin Fowler explains it in CollectionClosureMethod
And Matz slides at OSCON2005

Actually there are more points to it (how you can mold the language, to represent your domain)
(7.hours, meme.to_yaml, etc)

But the internal iterator + closures are very powerfull.

GUI Design and Usability

Links from FreeRide:RougeProject, the developer resources

Lambda, the ultimate

quotes

When close to natural language goes wrong

from here:

In English, these two statements ought to be considered synonymous:

path of fonts folder of user domain
path to fonts folder from user domain

But in AppleScript, they are not, and rather are brittlely dependent on the current context. In the global scope, the StandardAdditions OSAX wants “path to” and “from user domain”; in a System Events tell block, System Events wants “path of” and “of user domain”.