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

11–20 of 59 posts

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

#11

Post by bgraves »

sandal wrote: post #10
bgraves wrote: post #9

Earlier quoted context omitted.

Thank you for the details! Much appreciated. Even though you may not have been paid a "fair wage" for the work that you put into this book, it sounds like you are very happy with the outcome and the experience and the future benefits that you will undoubtedly reap from this project. Congratulations and thanks again!

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.

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

#13

Post by lg »

richcollins wrote: post #12

Keyword arguments via hashes is certainly not a best practice for "Beautiful API Design". Sending messages is part and parcel to good OO design. Code that deconstructs hashes to emulate keyword arguments is invariably hideously complicated.

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

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

#14

Post by jellisjapan »

sandal wrote: post #10
bgraves wrote: post #9

Earlier quoted context omitted.

Thank you for the details! Much appreciated. Even though you may not have been paid a "fair wage" for the work that you put into this book, it sounds like you are very happy with the outcome and the experience and the future benefits that you will undoubtedly reap from this project. Congratulations and thanks again!

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…

Could you explain a little bit more about the "logistical nightmare" aspect of self-publishing? I'm thinking about self-publishing a book of my own, so I'd love to hear more about the obstacles you came across and how publishers make it easier.

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

#15

Post by sandal »

richcollins wrote: post #12

Keyword arguments via hashes is certainly not a best practice for "Beautiful API Design". Sending messages is part and parcel to good OO design. Code that deconstructs hashes to emulate keyword arguments is invariably hideously complicated.

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 things down into small functions that each do their part is a good way around this, but these tend to be hard to extend dynamically.

Typically well designed Ruby systems provide both: Pseudo keyword arguments for dynamic needs, and some DSL-type syntax for pleasing the eyes.

Yes, it sucks that we don't have real keyword arguments. But no, it's not nearly as bad as you think.

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

#16

Post by [deleted] »

jellisjapan wrote: post #14
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…

Could you explain a little bit more about the "logistical nightmare" aspect of self-publishing? I'm thinking about self-publishing a book of my own, so I'd love to hear more about the obstacles you came across and how publishers make it easier.

[deleted]

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

#17

Post by sandal »

jellisjapan wrote: post #14
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…

Could you explain a little bit more about the "logistical nightmare" aspect of self-publishing? I'm thinking about self-publishing a book of my own, so I'd love to hear more about the obstacles you came across and how publishers make it easier.

Well, I think that it can be profitable, especially if going EBook only. There is some great advice on it here:

http://macournoyer.com/blog/2010/03/01/promote-cyopl/

But for me, I didn't want to spend a ton of time and effort on marketing, and my topic was a niche within a niche at the time (I wrote the Ruport Book with Mike Milner -- ruportbook.com).

After a year or so, instead of being thousands in the black, we were hundreds in the red, even though the book sold a few hundred copies. So we just made it available at cost and closed the doors at that point.

This may be because the HTML version was available for free when we started. It may be because we set price points very low (I think our PDF was like $8), it may be because I started an LLC and wasted tons of money on absurd taxes just for keeping the doors open. It was a bunch of epic fail on the business side of things, and that at least taught me a lesson.

I talked to O'Reilly and though they were very inflexible about certain things (due dates, typesetting, etc), they were open to change pretty much everything that mattered to me, and did. As a result, my book shipped early and at a much higher quality level than I could imagine doing myself.

Of course, I could tell you stories about other publishers I either pitched ideas for, did tech editing with, or wrote chapters for that'd make your head spin. So I wouldn't say that professional publishers are good across the board, just O'Reilly pretty much let me run with my ideas and ended up being very accomodating.

This may have something to do with the fact that I blogged and wrote articles with them for a while before writing a book, and because my editor is also a friend of mine from the Ruby community. But I know folks who have pitched O'Reilly cold and had similarly positive experiences, so I don't think that's the case.

Ultimately, publishing is going to be what you make of it. Self-publishing gives you full control, but it also gives you full responsibility. I think you can make money on it if you market effectively, and I think it can be a worthwhile if you really want to do something unique.

But for me, someone who just wanted to get some ideas out there and maybe make a buck or two in the process, doing all of the work of self publishing really was horrible.

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

#18

Post by richcollins »

sandal wrote: post #15
richcollins wrote: post #12

Keyword arguments via hashes is certainly not a best practice for "Beautiful API Design". Sending messages is part and parcel to good OO design. Code that deconstructs hashes to emulate keyword arguments is invariably hideously complicated.

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). If you have more than two arguments to a method, it's a sign that you should reify them into an object.

Using block based DSLs so that you can break things down into small functions that each do their part is a good way around this

Why do people love making things complicated by misusing blocks. Just create an object and set slots on it. Blocks are best used for delaying computation, not setting up state.

I think that Zed Shaw's essay on the "Master" and the "Expert" is applicable here: http://www.zedshaw.com/essays/master_and_expert.html

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

#19

Post by richcollins »

lg wrote: post #13
richcollins wrote: post #12

Keyword arguments via hashes is certainly not a best practice for "Beautiful API Design". Sending messages is part and parcel to good OO design. Code that deconstructs hashes to emulate keyword arguments is invariably hideously complicated.

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.

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

#20

Post by daveungerer »

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.

Post reply on HN