Contextual Validation

I found this blog about "where the validation should take place".
I always felt that the validation belongs to the domain.
I think that the best solution would be to have one/several validation rules, in the domain,
which are used by the controllers.

Also Martin Fowler blogs about it, and check the Hibernate Validator.

The Monkey Knife Fight

Funny stuff found here, on the human interface debate.
also this and this is interesting.

Languages History

Paul Graham offers a nice language comparison here.
Also the "21st Century Digital boy" here.

What's old is new again...

Human Inteface Debate (redux)

Blaine Buxton puts the "." on the "i" here.
It is all about code-organization. Every class has different views How you organize these categories, (different views), is another bussiness.
You can use Utilities-Classes, or you can extend classes and add method categories, or you can use Aspects, or traits, or mixins...

ps. Good read: the Bernard Notarianni's "Object Orientation Enlightenment".
Maye it should deserve its own post...

And today, I realized what I missed.

The important part is not the code: it is the upper part with classes, protocols and methods. Programming with Smalltalk is actually creating meaningful class’s names, meaningful methods names and organize them into self explicatory protocols.

Scrum for Microsoft

Nice to hear.
As we all know, Scrum is XP for project managers.

But:

David Treadwell, corporate vice president of the .Net Developer Platform group at Microsoft, said that while Microsoft welcomes the use of methodologies like Scrum, "we're not mandating them, but we're encouraging them. So Scrum is one process—the idea that teams meet once a day for half an hour, figure out what they're going to do then go off and do their work very quickly.

"The other is extreme programming—the concept where you might have two people working on a given piece of code and the idea is that two minds are better than one. Because you can find problems faster."

Mr. Treadwell has no idea what XP is. XP contains the Scrum practices (different naming though), the iterations are finer, and there are extra-practices related to development. Scrum is focused only on project-management. No TDD, no pair-programming is specified.

Java (.Net) Style vs Smalltalk (Ruby) Style

originally here, with answers/comments here and here.

Well I think that both parties are wrong/right.

78 Methods is a little bit too much, but in Smalltalk the Classes are extended and I believe that the 437 methods for the Object class are meant to be there. (And not in the Object-Utilities class like the C#3.0 way).

Second to that, you *must* love the way methods/classes can be categorized in Smalltalk.
It's like a quick-sort for my eyes, tired of scroll-down, scroll-down.

I must go back to C#: actually the whole "utilities" stuff, in the C#3.0 is a hack for extending/categorizing classes and methods. We will have: Object-Xml-Utilities, Object-JSON-Utilities and lots and lots of other Utilities (or Categories !?).

3rd, access by index in a List is wrong !!! The whole concept of hiding the implemetation has vanished. I don't want to write list.get(list.size() - 1) !!! This is clearly a code-smell. All the references in the code snippet are to the list, so the list should/must contain the method which wraps this code snippet , i.e. list.last() method.

Some really nice metaphors:

The cell phone is a great mental model for how to design a class. You just punch in the number of the person you want to speak to, and the phone takes care of the rest. You don't need to know anything at all about how the cell network operates, how it interfaces to the land-line system, or anything else for that matter, to complete your call. The phone is a black box with an intention revealing API.
[isomer]

Alan Kay has lamented publicly on more than one occasion that he should have called it Message Oriented programming to drive home the idea that designing the correct messages is of paramount importance.

With bitterness: "The only thing we learned from history is that we did not learn anything from history."

ps.

But there's more wrong with the collections in Java: optional methods Which means the implementation may or may not support the method. This is one of the benefits of static typing. You know at compiletime that the instance will have the method.

The same disease has the .Net Framework. Just look at the IList implementation of the Array.
"... Always throws NotSupportedException". The class Array is clearly lying about fulfilling its contract, to implement IList interface. What are the benefits of static-typing in this case, compare to dynamic typing + #messageNotUnderstood?