Had a lot of trouble getting this to work kept complaining about forbidden attributes. Changing line 3 from @project.update_attributes(params[:project])
to
@project.update_attributes(parameter_params)
seemed to fix it
I know realise that this was down to the [ CA] line continuation in the code, which in ignorance I had typed in from the example, but left out when I found a similar example of using a timer elsewhere on the web.
When I enter the code as printed for the NSTimer and then run the project, I get exit with status 1. If I leave out the brackets and use:

@pomodoro_timer = NSTimer.scheduledTimerWithTimeInterval 60, target: self,
selector: "min_passed:", userInfo: nil, repeats: true

things work as expected.
What is the [ CA] for in some of the method calls. Sometimes it's there and sometimes it isn''t. For instance on page 18/19 you show how to use the NSTimer method and use [ CA] in front of the :selector parameter in each case, but only in the final example do you use [ CA] in front of :repeats.

There is a small typo on page 18 section 1.4.3 the objective-c NSTimer example has [ CA} instead of [ CA]
Thanks for introducing me to MacRuby. I have recently bought my first Mac and am struggling with Cocoa, the first few chapters have improved my understanding of Cocoa as well as showing me that MacRuby is simpler.

On page 43 in def min_passed you have called timer_finished_alert this should be alert_user. This is correct in the complete listing 2.2
Figure 3.1 The completed Mortgage Calculatr App
->
Figure 3.1 The completed Mortgage Calculator App

Let’s take for an example a mortgage calculator. An ubiquitous part of any mortgage web site the user is able to enter in their loan amount, the rate, and how long they want to pay their mortgage out over.
->
Let’s take for an example a mortgage calculator, a ubiquitous part of any mortgage web site. The the user is able to enter in their loan amount, the rate, and how long they want to pay their mortgage over.

3.x.x Subsection here
->
3.5.1 The Mortgage Calculator Model

3.x.x Subsection here
->
3.5.2 The Mortgage Calculator View

Listing 3.x: title here
->
Listing 3.18: MortgageCalcView.groovy

The listings folowing then need renumbering

3.x.x Subsection here
->
3.5.3 The Mortgage Calculator Controller
The last options, and the preferable one,
should be
The last option, and the preferable one,
or
The last option, and the mostpreferable one,

This also serves to keep the information about the binding within the binding node. also has the nice side effect of making the code entirely declarative,
->
This also serves to keep the information about the binding within the binding node. It also has the nice side effect of making the code entirely declarative,

When it comes to binding one of the strengths can also be one of its grates weaknesses:
->
When it comes to binding one of the strengths can also be one of its great weaknesses:

And a lot of bindings happening at the same time has already gained a nickname -- a bindstorm where automatic updates fire en mass
->
A lot of bindings happening at the same time has already gained a nickname -- a bindstorm where automatic updates fire en masse

The unbind method also serves to do the opposite
->
The unbind method serves to do the opposite
I found this example somewhat confusing, that could well be because the book is aimed at much more experienced programmers than me, or it may be the way that I work through examples. Here are my observations:

The Model uses getPayment(), the View sourceProperty is 'payment'. Perhaps a few words on the magic that means that a property payment is automagically created when the getter is defined.

For 3.18 I would have liked the application(.....) code at the top.

I thought the code changes then given were in the wrong order, as the first change does not solve the problem that is most evident with the calculator, i.e. that it does not work out the Monthly Payment

I would then have liked you to point out that the Monthly Payment textbox reads NaN, because the textField values are strings and need to be converted to floats for use in getPayment()
Adding the converters then gives an answer in the Monthly Payment textbox.

Changing the values in the other textboxes does not then cause the Monthly Payment textbox to change as it is not updated. Then add the sourceEvent update binding.
3.3 Have your people call my people: Binding
In fact, as you write a Griffon application you are probably using some rather complex binging mojo without even knowing it.
should it be
In fact, as you write a Griffon application you are probably using some rather complex binding mojo without even knowing it.

 [ToDo Way #2]
An event to property binding?

 ToDoWay#3]
/?

3.3.x Subsection here about essence and ceremony
something like
3.3.3 Bindings: essence and ceremony


A [annotation here] - needs to be updated or removed. There are 2 of these.

The result of the fourth bind node would be the state of the secondCheckbox selection would be driven by the first checkbox.
should this read
The result of the fourth bind node would be that the selected state of the secondCheckbox would be driven by that of the first checkbox.

checkbox('Second',
selected: bind { firstChecBox.selected } )
not important but was probably meant to be
checkbox('Second',
selected: bind { firstCheckBox.selected } )

3.4.3 Other Bindings Options
should be
3.3.3 Other Bindings Options

checkbox("Check spelling before sending mail",
selected: bind(target:model, 'spelcheck', value:true))
not important and could be deliberate irony but I would have expected
checkbox("Check spelling before sending mail",
selected: bind(target:model, 'spellcheck', value:true))

The attribute bind: controls whether or not a biding will be set to automatically update.
should be
The attribute bind: controls whether or not a binding will be set to automatically update.
But the effect is the same: if you follow the cues you are presented a story where when something changes you are directly drawn to that change.
should this be
But the effect is the same: if you follow the cues you are presented with then when something changes you are directly drawn to that change.
or
But the effect is the same: if you follow the cues you are presented with a story where when something changes you are directly drawn to that change.

3.2.2-making difficult things possible
If the setter exists already by the user, then the body of the setter method is wrapped
should this just be
If the setter exists already, then the body of the setter method is wrapped

3.2.3 handybound classes
When it comes to property access, the map class in Groovy is one of the classes that get the most special treatment from the runtime as compared to some of the other classes.
should this be
When it comes to property access, the map class in Groovy is one of the classes that gets special treatment from the runtime.

When changing the objects the first set of events fire the identically,
should be
When changing the objects the first set of events fire identically,
As we discussed in Chapter 4,
the 4 is highlighted but still needs to be changed

The domain model is supposed to be ignorant of the UI and is supposed to serve the data needs of the particular data needs of the problem domain being modeled.
should this be
The domain model is supposed to be ignorant of the UI and is supposed to serve the particular data needs of the problem domain being modeled.

3.x.x Subsection here
there are 2 of these which should presumably be
3.1.1 The Domain Model
3.1.2 The Application Model
Models are to some extend a shared whiteboard,
should read
Models are to some extent a shared whiteboard,

If you know how the arithmetic and math behind it works it seems a lot less magical and conceptually easy to grasp why it works.
better might be
If you know how the arithmetic and math behind it works it seems a lot less magical and it becomes conceptually easier to grasp why it works.