Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby Best Practices (full book available for download)

blog.rubybestpractices.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Ruby Best Practices (full book available for download)

#21

Post by jamesbritt »

sandal wrote: post #6
bgraves wrote: post #4

So, is this the full version of the O'Reilly book [1] or something different? I'm curious about the business end of this project: did you sell this PDF before giving it away for free? How much revenue have you brought in? How much time have you spent writing/compiling/editing this book in it's current state. It seems like a very highly regarded book (judging from the Amazon reviews) so perhaps I am just out of the lo…

It is exactly what was used to generate the print book, just with some web enabled features like links. And yes, this is the PDF you'd get if you buy it from O'Reilly. Marketing-wise, it was a gamble, because the open source release date wasn't contingent on sales or anything like that. We launched the book and gave a 9 month exclusive rights period to O'Reilly. This at least takes into account the fact that most boo…

BTW, people should Google around for Gregory Brown's conference videos to hear him talk about, and demonstrate, assorted instances of good and bad code.

Re: Ruby Best Practices (full book available for download)

#22

Post by sandal »

richcollins wrote: post #18
sandal wrote: post #15

Earlier quoted context omitted.

I agree with you from a language design standpoint, but seriously, I doubt you have much Ruby experience if you're saying this. And if that's the case, you really don't have a basis to be commenting on my book in such a critical and dismissive way. Using positional arguments for more than two or so things creates connascence of position, which quickly becomes annoying. Using block based DSLs so that you can break thi…

I've been using Ruby since 2005 and I am a top 100 contributor to Rails ( http://contributors.rubyonrails.org/ ). Rails design suffers for its heavy use of "keyword arguments". positional arguments for more than two or so things creates connascence of position Which is precisely the reason that you shouldn't pass more than two arguments to a method (unless you are creating a list or hash for their intended purpose).…

Wow, and this is exactly the kind of douchebaggery I was trying to get away from in my book. You know, I think on the first page I mention that the answer to "what the best way" to do something in Ruby is always "it depends". The notion that you can follow singular design principles in all situations is absurd, if you ask me.

Context is king, and what you've done is taken a single point from my book, ripped out its context, strawmanned it to death, and used it to bolster you're own "Top 100 rails" status.

I encourage readers to actually see what I had to say in the book by downloading the PDF before taking these arguments too seriously. If there are some constructive examples to be shown that seem promising and pass peer review, they'll definitely make it into the open source version.

It might even be worth it to write up a section describing the tradeoffs that richcollins has pointed out, but it's definitely not something as universal as he makes it sound.

Re: Ruby Best Practices (full book available for download)

#23

Post by kogent »

richcollins wrote: post #19
lg wrote: post #13

Earlier quoted context omitted.

Would you prefer a *rest argument? An options hash is the best way to make your ruby API flexible.

Plain old objects are the best way to make your API design flexible. You can't easily change the behavior of setting a key/value pair for an individual hash. Objects are designed to implement behavior, Hashs are meant to hold key value pairs.

The book is opensource, why not submit a patch pull request. :)

Re: Ruby Best Practices (full book available for download)

#25

Post by sandal »

daveungerer wrote: post #20

The sandal username on GitHub sounded familiar, so I checked and realised its the same sandal that does the Prawn PDF library: http://github.com/sandal/prawn That gives the book some extra credibility in my eyes. EDIT: OK, now that I've read the foreward, I see Matz himself mentions Gregory's work on Prawn. Doh.

Yes, I started Prawn via the "Ruby Mendicant" project: http://majesticseacreature.com/mendicant/

I'm still active in the project as a maintainer. But really, these days you have Brad Ediger, James Healy, and Daniel Nelson, along with about 60+ contributors to thank for where Prawn is heading.

My job is mostly to sit around naming things, and warning people about the fragility of the early code I wrote. But we will have a 1.0 plan soon, and no matter who does the work, that'll be good for everybody.

Re: Ruby Best Practices (full book available for download)

#26

Post by sandal »

ddemchuk wrote: post #24
sandal wrote: post #2

For the tl;dr crowd, this will take you straight to the PDF: http://sandal.github.com/rbp-book/pdfs/rbp_1-0.pdf (But please read the article, it provides context :)

you provided a tl;dr link to a BOOK???! haha, wednesday morning irony ftw

Hah, the irony here did not escape me. But good point.

So... here's the tl;dr; for the book itself:

"Ruby provides many ways to do things, many of them decent. But some are usually better than others, depending on the context."

Re: Ruby Best Practices (full book available for download)

#27

Post by jamesbritt »

bgraves wrote: post #11
sandal wrote: post #10

Earlier quoted context omitted.

Actually, I don't think my advance was unfair. I self published a book a couple years ago and it was a logistical nightmare. When you think about what a publisher actually does, it's really a daunting task. I think there was a post here on HN about that recently, but I can't remember the link. The author who wrote it described pretty much the exact process I went through, even though I think he was working with anoth…

"fair wage" was a poor choice of words on my part. I didn't mean to imply that your payment was "unfair", but rather that minimum wage is to low (imo) for an advanced programming book.

Writing tech books is something of a crap shoot.

I had a mixed blessing with my first book effort, Pro VB 6 & XML. I started out as one of about 10 authors, expected to contribute one or two chapters, and ended up as one of two authors and writing a little over half the book.

I got to write about stuff I was already quite familiar with, so it went pretty quick. And the book did OK, so I made some decent money, and the time spent was well worth it.

However: It gave me the impression this was a repeatable event. :)

Aside from the odd chapter for Wrox (most of which never saw the light of day because books got canceled, though I still got paid since I was not on royalties for them), my next book effort was Beginning Ruby for Wrox, around 2001 or so.

Way more work, the tech market was turning to shit, and Ruby was still an uber-niche area. Wrox then went bankrupt, and I never saw my final check for work completed. I got, I think, a grand for several months work.

Just before Wrox burned I had some discussions with my editor who suggested various ways to monetize what I had already written. Mostly it was "have a Web site".

Thing is, there is so much free quality info already available that drumming up eyeballs and getting people to part with cash is quite tricky.

If you're thinking of writing a book you really need to have your eyes open and keep realistic expectations, and be comfortable with what you can expect. If the goal is to build a rep, then sales may not matter. But you are still competing for attention.

Greg has the Ruby Best Practices blog; I'm quite honored to be allowed to publish there (and I wish I could get my ass in gear to write more). I'd be all for having ads on the site and finding a way to get some cash back to Greg & O'Reilly so long as it didn't spoil the reader's experience.

But I think that's quite doable.

I also think E-books can do better by exploiting their E-nature. I've had some ideas for E-books that weren't simply paper books turned PDF. There is lot's you can do with them, and perhaps there are ways to hook them into a recurring revenue service (say, a subscription to Best Practices screencasts or something.)

I can't emphasize enough, though, that people who find these things valuable should see about remunerating the author. If you want to see more things like this, help out.

People like Greg deserve a lot of credit for trying things out and trying to provide quality material in an affordable way. He is one of the reasons I'm proud to be part of the Ruby community.

Re: Ruby Best Practices (full book available for download)

#28

Post by sandal »

kogent wrote: post #23
richcollins wrote: post #19

Earlier quoted context omitted.

Plain old objects are the best way to make your API design flexible. You can't easily change the behavior of setting a key/value pair for an individual hash. Objects are designed to implement behavior, Hashs are meant to hold key value pairs.

The book is opensource, why not submit a patch pull request. :)

In all seriousness, all it takes is some code examples that make me and a few others say "whoa, cool" and it'll make its way in.

If RBP becomes "Gregory Brown's Best Practices", it'll be epic fail. I am encouraging folks to prove whatever they can wrong in this book.

Re: Ruby Best Practices (full book available for download)

#29

Post by richcollins »

sandal wrote: post #22
richcollins wrote: post #18

Earlier quoted context omitted.

I've been using Ruby since 2005 and I am a top 100 contributor to Rails ( http://contributors.rubyonrails.org/ ). Rails design suffers for its heavy use of "keyword arguments". positional arguments for more than two or so things creates connascence of position Which is precisely the reason that you shouldn't pass more than two arguments to a method (unless you are creating a list or hash for their intended purpose).…

Wow, and this is exactly the kind of douchebaggery I was trying to get away from in my book. You know, I think on the first page I mention that the answer to "what the best way" to do something in Ruby is always "it depends". The notion that you can follow singular design principles in all situations is absurd, if you ask me. Context is king, and what you've done is taken a single point from my book, ripped out its c…

used it to bolster you're own "Top 100 rails" status.

I've mostly stopped using Rails and Ruby in favor of Io, so I have no interest in bolstering my Rails status. I was just providing evidence to counter your assertion that I was a Ruby newb.

The notion that you can follow singular design principles in all situations is absurd, if you ask me.

I agree that "it depends", but using Hashes as arguments has become idiomatic Ruby, which is unfortunate in most cases.

Re: Ruby Best Practices (full book available for download)

#30

Post by sandal »

richcollins wrote: post #29
sandal wrote: post #22

Earlier quoted context omitted.

Wow, and this is exactly the kind of douchebaggery I was trying to get away from in my book. You know, I think on the first page I mention that the answer to "what the best way" to do something in Ruby is always "it depends". The notion that you can follow singular design principles in all situations is absurd, if you ask me. Context is king, and what you've done is taken a single point from my book, ripped out its c…

used it to bolster you're own "Top 100 rails" status. I've mostly stopped using Rails and Ruby in favor of Io, so I have no interest in bolstering my Rails status. I was just providing evidence to counter your assertion that I was a Ruby newb. The notion that you can follow singular design principles in all situations is absurd, if you ask me. I agree that "it depends", but using Hashes as arguments has become idioma…

I wasn't assuming you were a newb, just that you didn't have much exposure to what are commonly regarded as well designed Ruby libraries. It didn't occur to me that you'd have had that exposure and yet sound as if you were shocked and appalled about what is common practice.

I still would really like to see examples of well designed open source Ruby projects that follow what you consider to be decent design principles. I think that'd make a much stronger case for your argument, and might open my eyes to something that's been in a blind spot.

Personally, I feel like a certain amount of API design is bound to what consumers will expect. We can certainly stretch and shift their tendencies, but if we fly in the face of them, our perfection in a vacuum will never be appreciated.

Post reply on HN