I've been thinking long and hard about the tutorial section of the PickAxe. It's the section of the book that seems to create the most emotion in readers: most folks seem to like the unconventional style (starting with classes and objects and working down) and some folks hate it. A while back, I asked here what people thought, and used what was said to guide me.
So this new beta of the PickAxe keeps the same overall structure for the tutorial. But I'm rewriting it to do two things:
1. I'm getting rid of the jukebox (loud cheers were heard throughout the land). The jukebox was always no more than a skeleton project on which to hang sample code illustrating points in the tutorial. But it never really went anywhere in the book. So now I'll be using smaller, self contained code fragments. Some of them are just targeted to show a particular Ruby feature, and others do (at least vaguely) useful work.
2. I'm being more opinionated when it comes to the ways you should write code. So, for example, I'm pushing class inheritance way back, and instead focusing on mixins as the preferred way of structuring the sharing of functionality. (Obviously, inheritance still has a place, but I'd like to see less instances of code like "class Product < ActiveRecord::Base')
Along the way I'm dropping in more 1.9 goodies.
So, if you're an existing beta reader, log in to your account and refresh your PDF. Be patient though, there's already a backlog...
"Thank you" to everyone who helped by expressing an opinion.
(If you'd like information on the book, it's at http://pragprog.com/titles/ruby3/programming-ruby-3)
Cheers
Dave
How about you just push against nonsensical names like Base?
class Product < ActiveRecord
makes _plenty_ of sense by itself. 
···
On May 28, 2008, at 09:07 , Dave Thomas wrote:
2. I'm being more opinionated when it comes to the ways you should write code. So, for example, I'm pushing class inheritance way back, and instead focusing on mixins as the preferred way of structuring the sharing of functionality. (Obviously, inheritance still has a place, but I'd like to see less instances of code like "class Product < ActiveRecord::Base')
class Product
include ActiveRecord
end
makes even more... After all, a Product is not an ActiveRecord--it uses the functionality.
Dave
···
On May 28, 2008, at 12:36 PM, Ryan Davis wrote:
On May 28, 2008, at 09:07 , Dave Thomas wrote:
2. I'm being more opinionated when it comes to the ways you should write code. So, for example, I'm pushing class inheritance way back, and instead focusing on mixins as the preferred way of structuring the sharing of functionality. (Obviously, inheritance still has a place, but I'd like to see less instances of code like "class Product < ActiveRecord::Base')
How about you just push against nonsensical names like Base?
class Product < ActiveRecord
makes _plenty_ of sense by itself.
ActiveRecord, though, is a module, and for good reason. The problem
isn't really with Base, but ActiveRecord, which would have been a much
better name for the class within the module than the module. (Sequel,
with Sequel::Model, is better than ActiveRecord in naming, among other
things.)
···
On Wed, May 28, 2008 at 10:36 AM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On May 28, 2008, at 09:07 , Dave Thomas wrote:
2. I'm being more opinionated when it comes to the ways you should write
code. So, for example, I'm pushing class inheritance way back, and instead
focusing on mixins as the preferred way of structuring the sharing of
functionality. (Obviously, inheritance still has a place, but I'd like to
see less instances of code like "class Product < ActiveRecord::Base')
How about you just push against nonsensical names like Base?
class Product < ActiveRecord
makes _plenty_ of sense by itself.
Actually - to extend the example - i really like the way DataMapper reads:
···
On May 28, 2008, at 8:01 PM, Dave Thomas wrote:
On May 28, 2008, at 12:36 PM, Ryan Davis wrote:
On May 28, 2008, at 09:07 , Dave Thomas wrote:
2. I'm being more opinionated when it comes to the ways you should write code. So, for example, I'm pushing class inheritance way back, and instead focusing on mixins as the preferred way of structuring the sharing of functionality. (Obviously, inheritance still has a place, but I'd like to see less instances of code like "class Product < ActiveRecord::Base')
How about you just push against nonsensical names like Base?
class Product < ActiveRecord
makes _plenty_ of sense by itself.
class Product
include ActiveRecord
end
makes even more... After all, a Product is not an ActiveRecord--it uses the functionality.
Dave
===
class Product
include DataMapper::Persistence
end
Uses Persistence, provided by DataMapper.
That includes both the Task of the Module and the Source where it comes from.
The main problem of ActiveRecord::Base is that Base is such a generic name. And it implies that every object that has to do with AR is based on it.
Regards,
Florian Gilcher