New Beta of PickAxe3

Ruby
1

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

2

On May 28, 2008, at 09:07 , Dave T. wrote:

  1. 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. :stuck_out_tongue:

3

On May 28, 2008, at 12:36 PM, Ryan D. wrote:

How about you just push against nonsensical names like Base?

class Product < ActiveRecord

makes plenty of sense by itself. :stuck_out_tongue:

class Product
include ActiveRecord

end

makes even more… After all, a Product is not an ActiveRecord–it
uses the functionality.

Dave

4

On Wed, May 28, 2008 at 10:36 AM, Ryan D. [email protected]
wrote:

   class Product < ActiveRecord

makes plenty of sense by itself. :stuck_out_tongue:

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.)

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 28, 2008, at 8:01 PM, Dave T. wrote:

still has a place, but I’d like to see less instances of code like

end

makes even more… After all, a Product is not an ActiveRecord–it
uses the functionality.

Dave

Actually - to extend the example - i really like the way DataMapper
reads:

===
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 G.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkg9qLQACgkQJA/zY0IIRZYLvgCfUebEiapDHM9hW6IZAaj97ql0
45sAmQH6Z5LzxrFTfcx/huRrFp+XWWnV
=6HvQ
-----END PGP SIGNATURE-----