[ADV] New Beta of PickAxe3

[Dave Thomas]

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

 

[Ryan Davis]

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.

 

[Dave Thomas]

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

 

[Florian Gilcher]

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

class Product
include ActiveRecord

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

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

 

[Christopher Dicely]

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