Sadly, I'd rather buy your book if I needed it than to pay for the info
to be included in the other books where I do not.
Sure. The problem is the use case of someone who's been wanted to play
with Rails all week. Finally has a long weekend, stops by Barnes & Noble
or CompUSA to find the appropriate books. They have a few, some are even
the latest version. He grabs them, takes them home, and starts reading:
"First, enter the console app, where you'll be able to execute ruby
statements with real-time feedabck. From console..."
and the reader goes "What? What conosle? What directory is it in?"
My first question would be "why the hell can't the idiot just look
online and figure this out in the first place like any of the rest of
us?!!??!" but since I know that's too simple...
I understand and yet you also mention the problem with this: the number
of different platforms it is on and the vast differences that each
provide. The install for Fedora Core is different from OSX, or Windows,
and probably Debian and BSD, etc.
A list of links to pages that have up-to-date information on installing
for each platform and the idiosyncrasies for each is a better solution
than attempting to claim to be all-knowledgeable for all platforms when
in reality the author is really only experienced in a very few of the
platforms mentioned. Those pages could then deal with the console and
the directories that everything can be found in, etc. and could be
changed according to new releases. This would make Ruby/Rails books less
likely to become obsolete to those same readers you discussed if the
installation procedures were to change; it wouldn't leave them high and
dry and with a $40 paperweight.
Think about it, we live in an age where the Internet rules, and we're
learning about a programming language that is used mostly for web
development but we're supposed to rely on a few pieces of paper to tell
us the most recent news about installer quirks, etc. Since those
installer quirks are more likely to change than the basic language(etc.)
is, I don't see the point in including such a chapter.
···
On Sun, 07 Oct 2007 23:33:21 -0400, Eric H. wrote:
On 10/8/07, Chad Perrin <perrin@apotheon.com> wrote:
Actually, as a first step in that direction a "common useful libraries"
book -- perhaps called "prospecting for gems", or something cleverer --
would be excellent. I don't mean a listing: I mean an honest-to-goodness
tutorial/primer on a bunch of great libraries/modules for common tasks.
Far better suggestion is what topics to write books and chapters about!
I suggest a GUI focused Ruby book that covers Qt, Tk, Wx, etc...
A game / graphics focused Ruby book... (could easily be integrated or connected with the GUI book)
A whole host of Ruby topics could be entire books based on one or two classes or modules or gems.
What we have enough of are books that are broad but not deep.
As an example: Pro ActiveRecord is a nice one, but an Expert ActiveRecord would be better...
Lots of topics to suggest.
Agreed ... then again, there are some other good books that don't even exist:
"Up and Running with Nitro and Og"
"Up and Running with Iowa"
"Pragmatic RSpec" (although I hear that's due in beta by the end of the year)
"ZenTest and Heckle Primer"
"Selenium ..."
"Watir ..."
"Cerberus ..."
There are some things Ruby has -- like Rails, Nitro, Iowa, RSpec, ZenTest, Heckle and many others -- that don't exist in the Perl world. So you can't say, as you can with Ruby/Tk, "Go learn from the O'Reilly Perl/Tk book and just translate the syntax from Perl to Ruby and you'll be on the air".
I think the real problem is not that every book on Ruby tells you how to install it. The real problem is that there doesn't seem to be an actual paid market for much beyond books about Rails and core Ruby. The other good stuff, like the things I've listed above, just isn't getting seen.
Then again, as a potential author, I'm not going to spend any time writing about things I don't use. So don't look to me for a Nitro or Iowa book, or a book about everything you wanted to know about Ruby on Windows systems.
Actually, as a first step in that direction a "common useful libraries"
book -- perhaps called "prospecting for gems", or something cleverer --
would be excellent. I don't mean a listing: I mean an honest-to-goodness
tutorial/primer on a bunch of great libraries/modules for common tasks.
I can do "gem list --remote" and get a listing of the gems and brief descriptions -- good enough to tell me whether I want to learn about them or not. And as far as "common tasks" are concerned, I think that's covered adequately by "The Ruby Way" and "Ruby Cookbook".
What *I* want is a book on Cerberus, a book on RSpec, a book on Selenium, Watir/Firewatir, etc. I know *what* these things can do, and I want to know how to get started doing them without having to decode RDoc and ri files!
···
On Mon, Oct 08, 2007 at 08:31:54AM +0900, M. Edward (Ed) Borasky wrote:
Actually, as a first step in that direction a "common useful libraries"
book -- perhaps called "prospecting for gems", or something cleverer --
would be excellent. I don't mean a listing: I mean an honest-to-goodness
tutorial/primer on a bunch of great libraries/modules for common tasks.
There exists a book that describes an assortment of gems. It think the stated idea was that this was some sort of "must have" collection, but it comes off more as "these are the gems I just happened to learn about in my year and a half of using Ruby."
On the other hand, Hall Fulton's The Ruby Way has , I think, something of a "How to do assorted common or interesting tasks" theme, and does mention some of the less hyped, but no less useful, gems and libs.
Publishers seem deeply interested in following proven paths. Most would rather publish the 100th dreary Rails book than the first Nitro or Iowa book.
It seems like an area ripe for self-publishing of brief, low-cost, PDF-only works.
···
--
James Britt
"Design depends largely on constraints."
- Charles Eames
This is EXACTLY the scenario that supports boosting page counts with the
continued detailed installation how-to's !
Why?
Though it means a few cents go to a few pages of stuff you may not think
you need, it helps to ensure that we begin to develop some well
documented and easy to access standard installations. That can
definitely help reduce problems.
Besides, you may not think you need to install it again anytime soon,
but what if your hard disk bites the big one? Hmmm?
Lightning storm, flood, you name it. No more installed Ruby. (unless you
buy a new mac in a month)
I'm not certain I follow your point here entirely(I can't tell if you're
for or against the installation chapter(s)) but in the case of a hard
drive crash, etc. I would do as I did in the beginning: JFGI.
AND I already did have a system crash less than 2 weeks ago and I had to
do a reinstall. Took me less than 2 minutes to handle the Ruby side of
it thanks to Google.
One problem with these though is that they change pretty fast don't
they? So by the time you'd finish publishing it would it be out of date?
The only thing worse than a book on how to install Nitro/Og is a book on
how to do it that is out of date and no longer applies
Some of those smaller PDF booklets (mongrel has one, ferret has one,
etc.) might be more realistic though and are at a price point that is
low enough that it's not that big a deal if it's not accurate in 4
months cause by that point you'll be "following along" some other way.
Excellent point. I think that would be the time to make something more
akin to a magazine(electronic or not) that one could subscribe to. We
have PHP, Linux, and a gazillion other magazines of the sort so one on
any of these would be just as easily welcomed.
That's the beauty of self publishing; for example, with the Humble
Little Ruby Book, I can update it, send it to Lulu, and have a fresh
paper copy next week (or PDF copy immeidately).
That sort of setup is far more agile than a "stock and ship" setup
like most traditional publishers.
--Jeremy
···
On 10/8/07, Philip Hallstrom <ruby@philip.pjkh.com> wrote:
>> Far better suggestion is what topics to write books and chapters about!
>>
>> I suggest a GUI focused Ruby book that covers Qt, Tk, Wx, etc...
>> A game / graphics focused Ruby book... (could easily be integrated or
>> connected with the GUI book)
>> A whole host of Ruby topics could be entire books based on one or two
>> classes or modules or gems.
>> What we have enough of are books that are broad but not deep.
>> As an example: Pro ActiveRecord is a nice one, but an Expert ActiveRecord
>> would be better...
>>
>> Lots of topics to suggest.
>
> Agreed ... then again, there are some other good books that don't even exist:
>
> "Up and Running with Nitro and Og"
> "Up and Running with Iowa"
> "Pragmatic RSpec" (although I hear that's due in beta by the end of the year)
> "ZenTest and Heckle Primer"
> "Selenium ..."
> "Watir ..."
> "Cerberus ..."
One problem with these though is that they change pretty fast don't they?
So by the time you'd finish publishing it would it be out of date?
The only thing worse than a book on how to install Nitro/Og is a book on
how to do it that is out of date and no longer applies
Some of those smaller PDF booklets (mongrel has one, ferret has one, etc.)
might be more realistic though and are at a price point that is low enough
that it's not that big a deal if it's not accurate in 4 months cause by
that point you'll be "following along" some other way.
Excellent point. Books should consider "online appendices" more often for
things like that.
I have to laugh when I thumb through a decades-old book and it tells me to
find something on archie or in comp.sources.
···
On Mon, 08 Oct 2007 13:38:54 -0400, Eric H. wrote:
A list of links to pages that have up-to-date information on installing
for each platform and the idiosyncrasies for each is a better solution
than attempting to claim to be all-knowledgeable for all platforms when
in reality the author is really only experienced in a very few of the
platforms mentioned.
--
Jay Levitt |
Boston, MA | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit. http://www.jay.fm | - Kristoffer
I understand and yet you also mention the problem with this: the number
of different platforms it is on and the vast differences that each
provide. The install for Fedora Core is different from OSX, or Windows,
and probably Debian and BSD, etc.
Hmmm ... Gentoo Linux:
# emerge rails
Fedora/CentOS/RHEL:
# yum install rails
Debian/Ubuntu:
# apt-get install rails
In all cases, the command will install the dependencies, such as Ruby.
Oh, yeah, you'll need a DBMS.
# emerge mysql
# yum install mysql
# apt-get install mysql
On Windows, there's Instant Rails, and on Macs there's Locomotive. That pretty much covers everything except Solaris and BSD. Does anyone want to round out my list with those two?
On Mon, Oct 08, 2007 at 09:07:44AM +0900, Peter Cooper wrote:
On 10/8/07, Chad Perrin <perrin@apotheon.com> wrote:
>
> Actually, as a first step in that direction a "common useful libraries"
> book -- perhaps called "prospecting for gems", or something cleverer --
> would be excellent. I don't mean a listing: I mean an honest-to-goodness
> tutorial/primer on a bunch of great libraries/modules for common tasks.
Since we're all throwing book titles around, you might be interested
in _my_ book that just entered MEAP. It's basically what you
describe.
Ruby in Practice
--Jeremy
···
On 10/7/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Chad Perrin wrote:
> On Mon, Oct 08, 2007 at 08:31:54AM +0900, M. Edward (Ed) Borasky wrote:
>> John Joyce wrote:
>>> Far better suggestion is what topics to write books and chapters about!
>>>
>>> I suggest a GUI focused Ruby book that covers Qt, Tk, Wx, etc...
>>> A game / graphics focused Ruby book... (could easily be integrated or
>>> connected with the GUI book)
>>> A whole host of Ruby topics could be entire books based on one or two
>>> classes or modules or gems.
>>> What we have enough of are books that are broad but not deep.
>>> As an example: Pro ActiveRecord is a nice one, but an Expert
>>> ActiveRecord would be better...
>>>
>>> Lots of topics to suggest.
>> Agreed ... then again, there are some other good books that don't even
>> exist:
>>
>> "Up and Running with Nitro and Og"
>> "Up and Running with Iowa"
>> "Pragmatic RSpec" (although I hear that's due in beta by the end of the
>> year)
>> "ZenTest and Heckle Primer"
>> "Selenium ..."
>> "Watir ..."
>> "Cerberus ..."
>>
>> There are some things Ruby has -- like Rails, Nitro, Iowa, RSpec,
>> ZenTest, Heckle and many others -- that don't exist in the Perl world.
>> So you can't say, as you can with Ruby/Tk, "Go learn from the O'Reilly
>> Perl/Tk book and just translate the syntax from Perl to Ruby and you'll
>> be on the air".
>>
>> I think the real problem is not that every book on Ruby tells you how to
>> install it. The real problem is that there doesn't seem to be an actual
>> paid market for much beyond books about Rails and core Ruby. The other
>> good stuff, like the things I've listed above, just isn't getting seen.
>>
>> Then again, as a potential author, I'm not going to spend any time
>> writing about things I don't use. So don't look to me for a Nitro or
>> Iowa book, or a book about everything you wanted to know about Ruby on
>> Windows systems.
>
> Actually, as a first step in that direction a "common useful libraries"
> book -- perhaps called "prospecting for gems", or something cleverer --
> would be excellent. I don't mean a listing: I mean an honest-to-goodness
> tutorial/primer on a bunch of great libraries/modules for common tasks.
>
I can do "gem list --remote" and get a listing of the gems and brief
descriptions -- good enough to tell me whether I want to learn about
them or not. And as far as "common tasks" are concerned, I think that's
covered adequately by "The Ruby Way" and "Ruby Cookbook".
What *I* want is a book on Cerberus, a book on RSpec, a book on
Selenium, Watir/Firewatir, etc. I know *what* these things can do, and I
want to know how to get started doing them without having to decode RDoc
and ri files!
Agreed -- and I'd like to see more of that sort of thing going on. In
addition, it seems the publishers are few and far between who understand
that free PDFs can serve as free advertising for paid hardcopy (though
more numerous in the Ruby world than elsewhere), so offering on-demand
hardcopies through "vanity press" services along with free PDFs would
likely be a great way to self-publish in many cases.
At least you'll find out for sure whether people like your book.
···
On Mon, Oct 08, 2007 at 12:04:34PM +0900, James Britt wrote:
Publishers seem deeply interested in following proven paths. Most would
rather publish the 100th dreary Rails book than the first Nitro or Iowa
book.
It seems like an area ripe for self-publishing of brief, low-cost,
PDF-only works.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
MacUser, Nov. 1990: "There comes a time in the history of any project when
it becomes necessary to shoot the engineers and begin production."
"Please, please, please do not do us the disservice of putting a
chapter(or more) on how to install Ruby/Rails."
I personally agree with that. Maybe the "installing something"
should instead be mentioned in a rather short Appendix
section at the end, if at all (i rarely have problems
installing something, and then usually only because the
author didnt provide install instructions, or the install
didnt work because its buggy ;> ).
It bores me to skip through 40 pages of that kind of stuff
when i open the book first
I must say, Pickaxe2 was a very nice book in overall, the
other ruby books were not as good and thus I was a bit disappointed.
I think there would be only two cases where I would buy a new
ruby book:
~ something similar in spirit like Pickaxe2
- something that highlights in DETAIL the Ruby+C (K&R book is
sooooo boring ...) world. In fact, personally I would like
such a book that bridges the Ruby-C world
(I am collecting all information locally too, and
expanding all the time, but I do lack a lot of C
specific knowledge still... so making bindings to simple
C code someone else wrote is still hard for me)
Ah... there may be one more example, which would be "advanced"
ruby that could include theoretical stuff as well. For example
sections about good solutions of something, even a little bit
math reasoning behind etc.. etc.. or efficient coding and
these kind of "hints" which are explained, and NON-TRIVIAL
let's see on the Mac alone, there is also a one-click installer, there is MacPorts (formerly darwin ports) with opt get...
and it's still best to do a manual install if you want to be sure which version you're getting.
the devil is in the details.
so that includes the (very commonly used for OS X 10.4) Hivelogic installation tutorial.
···
On Oct 8, 2007, at 9:53 PM, M. Edward (Ed) Borasky wrote:
Eric H. wrote:
I understand and yet you also mention the problem with this: the number
of different platforms it is on and the vast differences that each
provide. The install for Fedora Core is different from OSX, or Windows,
and probably Debian and BSD, etc.
Hmmm ... Gentoo Linux:
# emerge rails
Fedora/CentOS/RHEL:
# yum install rails
Debian/Ubuntu:
# apt-get install rails
In all cases, the command will install the dependencies, such as Ruby.
Oh, yeah, you'll need a DBMS.
# emerge mysql
# yum install mysql
# apt-get install mysql
On Windows, there's Instant Rails, and on Macs there's Locomotive. That pretty much covers everything except Solaris and BSD. Does anyone want to round out my list with those two?
I understand and yet you also mention the problem with this: the number
of different platforms it is on and the vast differences that each
provide. The install for Fedora Core is different from OSX, or Windows,
and probably Debian and BSD, etc.
Hmmm ... Gentoo Linux:
# emerge rails
Fedora/CentOS/RHEL:
# yum install rails
Debian/Ubuntu:
# apt-get install rails
In all cases, the command will install the dependencies, such as Ruby.
Oh, yeah, you'll need a DBMS.
# emerge mysql
# yum install mysql
# apt-get install mysql
On Windows, there's Instant Rails, and on Macs there's Locomotive. That
pretty much covers everything except Solaris and BSD. Does anyone want
to round out my list with those two?
It would be great if that's all there was to it. According to someone
else, one has to worry about the paths quite a lot and each platform
would need their translations supposedly, each also set on a half page
picture in the book. Though it's prudent to point out again that I
consider becoming familiar with the file and operating system a basic
skill of owning and using a computer in the first place, much less
actually programming on one.
I recently tried to help a summer intern install (or rather update) his
Ruby installation which he'd initially got from apt-get by doing just that.
Turned out to be a REALLY hairy mess; even rebuilding Ruby and rubygems
from source didn't work. We finally had to go down into the build dirs and
build zlib by hand (and yes, we'd tried installing 20 packages all named
libz or zlib or derivatives thereof).
I also seem to recall that apt-get rails installs it outside of the gems
world, or something funky like that.
···
On Tue, 9 Oct 2007 11:53:00 +0900, M. Edward (Ed) Borasky wrote:
Debian/Ubuntu:
# apt-get install rails
--
Jay Levitt |
Boston, MA | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit. http://www.jay.fm | - Kristoffer
1. cd /usr/ports/www/rubygem-rails; make install clean
2. portinstall rubygem-rails
Just pick one, depending on whether you use portinstall, and go with it.
Should work just fine.
···
On Tue, Oct 09, 2007 at 11:53:00AM +0900, M. Edward (Ed) Borasky wrote:
Eric H. wrote:
>I understand and yet you also mention the problem with this: the number
>of different platforms it is on and the vast differences that each
>provide. The install for Fedora Core is different from OSX, or Windows,
>and probably Debian and BSD, etc.
Hmmm ... Gentoo Linux:
# emerge rails
Fedora/CentOS/RHEL:
# yum install rails
Debian/Ubuntu:
# apt-get install rails
In all cases, the command will install the dependencies, such as Ruby.
Oh, yeah, you'll need a DBMS.
# emerge mysql
# yum install mysql
# apt-get install mysql
On Windows, there's Instant Rails, and on Macs there's Locomotive. That
pretty much covers everything except Solaris and BSD. Does anyone want
to round out my list with those two?
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
MacUser, Nov. 1990: "There comes a time in the history of any project when
it becomes necessary to shoot the engineers and begin production."
What *I* want is a book on Cerberus, a book on RSpec, a book on
Selenium, Watir/Firewatir, etc. I know *what* these things can do, and I
want to know how to get started doing them without having to decode RDoc
and ri files!
I hear rumors about such things from time to time. They may happen.
Until then, use the Peepcode screencasts for RSpec - there's three. He
covers everything from the basics up to custom matchers. He stops
short of Story Runner, but Pat Maddox did a screencast on Story
Runner. It's basically four hours of video training total. Pat's
screencast is free and the Peepcode ones are cheap. I put them on my
iPod for workouts.
Also, personally, I are teh scuk when it comes to TDD, it's absolutely
my worst point as a developer, so I'm going to the Pragmatic Studio on
TDD with Rails. I think I actually know on an intellectual level a lot
of the stuff they'll be teaching, but it'll be good to have it
properly ironed into my brain.
- something that highlights in DETAIL the Ruby+C (K&R book is
sooooo boring ...) world. In fact, personally I would like
such a book that bridges the Ruby-C world
Well ... there's always the SWIG documentation online specific to Ruby:
(I am collecting all information locally too, and
expanding all the time, but I do lack a lot of C
specific knowledge still... so making bindings to simple
C code someone else wrote is still hard for me)
Ah... there may be one more example, which would be "advanced"
ruby that could include theoretical stuff as well. For example
sections about good solutions of something, even a little bit
math reasoning behind etc.. etc.. or efficient coding and
these kind of "hints" which are explained, and NON-TRIVIAL
