From now on, new posts will be published on usingimho.wordpress.com
Bye!
From now on, new posts will be published on usingimho.wordpress.com
Bye!
In ruby, you can do this:

Class methods mocking
Hum. Static’s bad, don’t do static, mkay? Well, not necessarily. The fact that you can test class methods like this makes them much more usable than they are in C#, where using static all over the place brings your design to the dumpster pretty quickly. Still, the use of class methods usually covers for underlying design flaws, so it’s a technical debt and you should evaulate what is convenient to do case by case.
The above snippet is powered by mocha, a mocking framework for ruby. It has a JMock-like syntax and it provides you all the usual tools.
mock()
creates a mock object. You can set expectations on a mock object with
mock_object.expects(:method_name)
and stubs with
mock_object.stubs(:method_name)
Expectations are verified at the end of the test: if you’ve set an expectation for :method_name and that method isn’t called on the mock object before the end of the test, that test will fail (no need to VerifyAllExpectations or such). Instead, stubs do not fail the test if not called.
So, in the following example:

if we remove the object.second call from the method run only the second test fill fail.
As seen before, you can set expectations and stubs not just on mocks but on any object, even class objects. Abusing of this feature, as to say in object = Object.new; object.expects(:method) , is probably not wise but as shown in the first snippet this allows testing of usually not testable situations.
You can force constraints on expectations using with(param_value) and you can return values with returns(value). For example, the following code:
mock_object = mock()
mock_object.expects(:get_capital).with('sweden').returns('stockholm')
Sets an expectation on mock_object for the method get_capital, the expectation is satisfied only if get_capital is called with the string 'sweden' and, if called that way, returns the string 'stockholm'. Of course you don’t need both clauses to be present togheter, mock_object.expects(:get_capital).with('sweden') and mock_object.expects(:get_capital).returns('stockholm') work just as expected. If you don’t set a return value for any given expectation/stub it will return nil.
stub_everything() returns a mock object that stubs every possible method call. The return value will always be nil.
More on mocha will be found on its documentation page.
LinqToSql tries to do what you want. NHibernate tries to do what you tell it to do. BIG difference, as you can see from the following snippet:

what I do expect to happen here is userToPersist alone being saved in database after SubmitChanges. What happens instead is userToPersist AND user being saved.
Hundreds and hundreds of future mapping files to write aren’t gonna move me away a single step from NH until THIS is what i get from competitors…
Yesterday I stumbled into this through hacker news and well, maybe the guy hasn’t really grasped the whole client-server paradigm thing but here he really made a point :
We’re engineers, and we make machines work. You use the best tool for the job to do that. You don’t choose some pretty language [Ruby] that “brings back the joy of coding” or equivalent hippy shit.
And more:
C is the dominant language right now and probably for the distant future. It’s the lingua franca of computing. Nearly every server application worth a damn is written in C.
Well, the guy here maybe needs to chill out a bit but I think he’s right: C is here to stay. Planning to use anything else for a large project where performance is crucial is insane (Java and C#, you heard me
). C is a really powerful and valuable tool, and every developer should have at least some knowledge of it: I started out with C64 Basic, then Assembly for a long, long time, then lots of C, after that Java, VB, C# and then Ruby. I know people like Why are promoting Ruby as a learning language but honestly, I can’t really imagine someone with no knowledge of C writing good Ruby.
But probably in the 70′s somebody made similar statements, just replacing C with FORTRAN. Right now, C is the language. What about it in 10 years? I’m really, really surprised every time I read such statements: they make me feel like story never happened. No wonder Berlusconi is gonna win the elections with 70% of the votes next week.
And even if C is the best all-purpose tool we have now, what’s the point in using it even if the situation would allow a not-so performant but much more pleasant to use tool instead? Is there some kind of pride to gain in being miserable doing your job that I’m not seeing? Ruby performs like crap, but it’s a pleasure to work with. And 99% of the times nobody cares about performance.
All these things have been said countless times by people way more authoritative than I will ever be but it seems there’s still need to state them clear…
I was watching this yesterday and the first thing that came into my mind was (of course) whoa, this is SO awesome . And the obvious follow through was that’s not gonna be just this. Google is making up something REAL big. Will it be an OS?
What if google releases a full fledged OS in a couple of years? Something that’s going to change the way we think about OS , the same way Wave will change our standards about messaging? What will Microsoft do then? Is it ready for the challenge?
I don’t really think so: there’s not been any real user experience innovation in OS since Xerox and Microsoft had all the time and resources in the world to think about something new and clever. It’s out there to see that they didn’t, and if Google really comes out with an OS i think it will be something Microsoft’s products can’t even compare to.
The only reason Microsoft is still alive and well is its privileged position in the OS market. Better for them if they start thinking about what to do next right now, or Google is gonna wipe them out.
I’m not really sure if that’s good or bad though.
I was at a customer today and they had a quite interesting situation to show me, and here it is.
Let’s create these dummy entities:

Entities
And now let’s register them the same way they did and see what happens when trying to resolve a Person:

As you can see Windsor actually “resolves” both Address and Job as if they were a dependency, setting both of them as a new instance! I don’t really think this is a bug but it’s totally not what I expected…
Having interfaces in between (so IPerson, IAddress and IJob) and then trying to resolve IPerson solves the “problem” (so I get a person with null Address and Job).
Not having the compiler on your side makes life difficult. Example:
C#
public int Multiply(int firstFactor,int secondFactor)
{
return firstFactor*secondFactor;
}
Ruby
def multiply(first_factor, second_factor) return first_factor*second_factor end
What these methods are supposed to do is pretty straightforward. What they actually do, maybe not so. What if you were to test both methods? What\how many tests would you write to make sure these methods behave as you expect?
Let’s take a look at the C# method. It takes two parameters (both int, so value types) and returns an integer. Relying on cyclomatic complexity to determine, for a given method, how many tests must be written is often uncorrect but let’s assume that it’s okay for this case, so one test that verifies the result for a given input might be enough.
What about the Ruby method? It takes two parameters and returns something. And the two parameters might be pretty much anything. How about testing this one? There’s no IFs so we might say that one test is still fine, or you might want to check parameters for correctness, or maybe make sure that who calls your method do it the way it’s supposed to. Either options (except the first but seriously, you’re not going for that one) requires extra effort in comparison to the C# approach.
About mocking:
C#
public Controller(IView view, IModel model)
{
//some stuff happening here
}
And Ruby
def initialize(view, model)
#some stuff happening here
end
Mocking view and model in C# requires some degree of IView = repo.CreateMock<IView>(). This relies on the IView interface, and you’ve got nothing like that in Ruby. You just mock methods instead. Mocha syntax:
def test_refresh_always_callRefreshOnView view = Mock() view.expects(:refresh) controller = Controller.new(view,Stub()) controller.refresh end
No need of VerifyAllExpectations() or such: this fails automatically if refresh is not invoked on the view object.
A similar problem arises when using IoC containers: you’ve got no interface to resolve. More about this later.
I’m an engineer: I can see up to 16 colors and I normally use 4 plus black and white, I’ve got a shortcut for terminal, I use that often and come on, what the f*ck is MistyRose supposed to be. Still, or maybe especially for those reasons, I found this to be very interesting and i suggest you to give it a look: it is for me what VBA macros are to the average programming noob
As I said some posts ago, there is no support for GUI building with Ruby inside NetBeans or any other Ruby IDE (with the exception of Komodo). That means you’ll have to rely on external tools, namely the Qt Designer or the Glade interface designer (for GTK+): they are plentiful in features, really easy to use and documentation is widely available so it will be not a problem for you to create good GUIs with them in no time. The only problem about using one of these tools instead of building your GUI with your favourite IDE is that you’ll have to integrate your interface (externally built) with the code you’re writing. Let’s see how, using Glade and GTK+.
After creating a new Glade project some windows will pop up. Among them will be the palette window and the properties window : the first one allows you to create new widget, so click on the upper left button to create a window widget, then add a button to the newly created window by selecting the button widget and then left-click on the window body.

Palette window
Now it’s time to look at the property window. By selecting the button that you craeted the property window will show all its properties. Select the signals tab and then click on the ellipse on the lower left of the window: that will show a dialog containing all the button’s available signals. Double click on clicked, then click add on the signals window.

Signals window
Now save the project and close the Glade designer. You will see that Glade created two files in the folder you chose: the one that cares to us it the yourprojectname.glade file. Now open a terminal at the folder location and type in:
ruby-glade-create-template yourprojectname.glade > yourrubyfile.rb
Where yourrubyfile is a filename of your choice. This will create a new yourrubyfile.rb that looks like:
#!/usr/bin/env ruby
#
# This file is gererated by ruby-glade-create-template 1.1.4.
#
require 'libglade2'
class yourrubyfileGlade
include GetText
attr :glade
def initialize(path_or_data, root = nil, domain = nil, localedir = nil, flag = GladeXML::FILE)
bindtextdomain(domain, localedir, nil, "UTF-8")
@glade = GladeXML.new(path_or_data, root, domain, localedir, flag) {|handler| method(handler)}
end
def on_button1_clicked(widget)
puts "on_button1_clicked() is not implemented yet."
end
end
# Main program
if __FILE__ == $0
# Set values as your own application.
PROG_PATH = "yourprojectname.glade"
PROG_NAME = "YOUR_APPLICATION_NAME"
Project1Glade.new(PROG_PATH, nil, PROG_NAME)
Gtk.main
end
Running the file will display the window you created and clicking on the button will execute whatever logic you’ve put inside the on_button1_clicked method.
As you might know Jeff Atwood and Joel Spolsky, during one of their podcast at stackoverflow, argued against the SOLID principles (defining them “idiotic”) going as far as saying “quality does not matter that much”. This triggered a blog reaction from Uncle Bob himself, which then led to another podcast and well, you can keep up with the story yourself from this point.
Of course I’m no match for these giants: i’ve got neither right nor intention to criticize their points of view. Still, I couldn’t really understand: why are they (both sides) so mad at methodology?
Let me explain. It seems that just a little share of the so-called programmers can actually program. But there’s more : even among this elite the difference between the best and the worst are of orders of magnitude. And worse : you can’t really learn it.
So, what the hell? There’s a huge amount of software that needs to be written out there, who’s gonna do that? Just the elites from the elite? Wait, here’s the solution: Methodology! You don’t need the gift, just blindly and faithfully follow the Instructions and everything’s fine! What a breakthrough!
And I’m serious about that. I’ve seen that in action, it costs – a LOT – in terms of productivity but you can actually make people that have no clue about programming building quality software. Take a Methodology and enforce it brutally: there’s no “maybe i’m doing this my way” or “let’s just patch it up for the next release”. Everything must be done by the book. It works. And i think it’s not a bad thing, of course unless Jeff and Joel are right and quality really doesn’t matter : but i like to think that’s not true – even knowing that i’m probably wrong.