Thank you for writing this, and thanks for open sourcing it.
Ruby Best Practices (full book available for download)
41–50 of 59 posts
Re: Ruby Best Practices (full book available for download)
#42Earlier quoted context omitted.
Right, the keys/values need to have supporting logic. And yeah if you're sticking procs in a hash, just use an object; but if your object is just a bunch of fields, use a hash. And often that's all you need. I just want to override the marginWidth on this fooBar. Remember you don't need to destructure the hash. You've got a local one initialized to sensible defaults, and you .merge! it with the param one, and then ju…
If your object is a bunch of fields, you should still use an object. It might need behavior later. I think the central issue is that there is too much friction to creating new classes in Ruby. It feels official and final. In Io, you just clone an existing object like you would send any other message.
There's also an embrace of YAGNI and "Do the simplest thing possible ..."
I'd rather start with a hash and then see if it later demands more, than start inventing objects that, based on existing use cases, need only be hashes or structs.
I'd also rather go through a number of pre-1.0 iterations to get real-world usage to shake out the painful API parts. Up until then I'm happy to break compatibility if experience says there's some bad code in there.
Monkeybars, for example, had some methods that began life using positional args, but they were changed to use hash values. I hated it.
Aside from the extra typing required for every call, with positional args I got used to reading code and seeing things in a fixed order, so when I had to use the method myself I knew exactly what needed to go where. (These methods had 2 arguments, with maybe an optional third or so.)
With the hash args the order could vary so I had to keep looking up what the possible argument key values could be.
(Thing about using hashes for args: with positional arguments you need only know what role an argument is playing in order to know what sort of value to pass in, but with a hash you have to know the exact key name. That ends up being more stuff to look up in the docs, especially if the API designer has a quirky way of naming things.)
You might think that at least for a code reader the use of hash keys would better document the call, but the method name and the names of items being passed in were almost always sufficient.
I suspect this particular change was a result of over-thinking these methods and expected usage instead of actually paying attention to what the code was doing right now, and how people were using it right now.
There are times when my gut tells me, "You know what's going to happen with this code later", and I try to take that into consideration, but (usually) simple wins for me.
Re: Ruby Best Practices (full book available for download)
#43Thank you for writing this, and thanks for open sourcing it.
The Ruby community has taught me so much, it seems the reasonable thing to do. Also, old books tend to go out of print, and then die sad, lonely out-of-date deaths.
Maybe this will keep RBP moving forward, and keep it alive.
Re: Ruby Best Practices (full book available for download)
#44BTW, going to experiment with using a wiki page for collecting reader questions. Once I have a few lined up, I'll cut a blog post reply on the RBP blog.
http://wiki.github.com/sandal/rbp-book/questions-for-gregory
Re: Ruby Best Practices (full book available for download)
#45Earlier quoted context omitted.
If your object is a bunch of fields, you should still use an object. It might need behavior later. I think the central issue is that there is too much friction to creating new classes in Ruby. It feels official and final. In Io, you just clone an existing object like you would send any other message.
There's also an embrace of YAGNI and "Do the simplest thing possible ..." I'd rather start with a hash and then see if it later demands more, than start inventing objects that, based on existing use cases, need only be hashes or structs. I'd also rather go through a number of pre-1.0 iterations to get real-world usage to shake out the painful API parts. Up until then I'm happy to break compatibility if experience say…
With the hash args the order could vary so I had to keep looking up what the possible argument key values could be.
You can set slots on objects in any order that you want to:
Foo.new.set_x(x).set_z(z) ...Re: Ruby Best Practices (full book available for download)
#46Earlier quoted context omitted.
There's also an embrace of YAGNI and "Do the simplest thing possible ..." I'd rather start with a hash and then see if it later demands more, than start inventing objects that, based on existing use cases, need only be hashes or structs. I'd also rather go through a number of pre-1.0 iterations to get real-world usage to shake out the painful API parts. Up until then I'm happy to break compatibility if experience say…
With the hash args the order could vary so I had to keep looking up what the possible argument key values could be. You can set slots on objects in any order that you want to: Foo.new.set_x(x).set_z(z) ...
That is insanely ugly. I will pass, thanks.
Re: Ruby Best Practices (full book available for download)
#47So, 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…
Hey Gregory, thanks a lot for sharing your experience and of course for the book itself. I'm just beginning to write an R graphs cookbook. Do you have any tips for a first time author?
Re: Ruby Best Practices (full book available for download)
#48Earlier quoted context omitted.
There's also an embrace of YAGNI and "Do the simplest thing possible ..." I'd rather start with a hash and then see if it later demands more, than start inventing objects that, based on existing use cases, need only be hashes or structs. I'd also rather go through a number of pre-1.0 iterations to get real-world usage to shake out the painful API parts. Up until then I'm happy to break compatibility if experience say…
With the hash args the order could vary so I had to keep looking up what the possible argument key values could be. You can set slots on objects in any order that you want to: Foo.new.set_x(x).set_z(z) ...
Can you recommend an Io book for me? I want to hunt down the author and try to encourage them to make their code more Rubyish. Because you know, that's helpful.
Re: Ruby Best Practices (full book available for download)
#49Earlier quoted context omitted.
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…
Hey Gregory, thanks a lot for sharing your experience and of course for the book itself. I'm just beginning to write an R graphs cookbook. Do you have any tips for a first time author?
Like most authors, I'll encourage you to think about not doing it, first :)
If you're just looking to get your ideas across, you'll almost certainly get more mileage out of writing articles, doing talks, etc.
And if you're looking to make money, unless you get very lucky, you won't make it directly off your book. It will almost certainly lead you towards other opportunities, but really all it creates is potential, things won't fall into your lap.
Still not discouraged? Then you might really, really want to write a book. That alone is what got me through the two I wrote. So then, go for it!
Here are some rough tips:
0) Get to know publishers a bit before submitting a proposal. I've had friends who got their book accepted cold, but really, there's little to differentiate you from the giant stack of proposals publishers receive daily if you come in without them knowing who you are first. This will also help you quickly identify the sort of people you don't want to work with. :)
1) Have a vision for your book. Get a sense of what you want it to be before you start writing it. This can be something very flexible, and doesn't need to button down any specifics, but know what the structure will be and test it out by attempting to write a chapter against it. If that doesn't work, reiterate. If you are working with a publisher that enforces a particular style, make sure you love it. But avoid those sort of restrictions if at all possible. I've written chapters on books where I was forced to write in a way I didn't like, and it was terrible.
2) Get together a good advisory group. Find the people you look up to in your topic area and ask them to discuss your chapters as you write them. We had a private mailing list for this in RBP, and it was amazingly effective. While tech reviewers can turn up a lot in isolation, you uncover the core issues when you ask them to discuss things as a group.
3) Expect your topics to change somewhat. If you find a chapter extremely hard to write, but there is a suitable replacement, consider introducing it. Completeness is a virtue, but I rather leave something out than cover it poorly. Some chapters will be hard due to necessary complexity, and that's okay. But there are others that are hard just because there is no reasonable way to write about them given your resources. Avoid those.
4) Write steadily, and try to make sure you're producing new content every week. Don't obsess over individual chapters, keep the whole of the book in mind. Leave yourself time to go back and breathe life into your more anemic content, but be sure to keep on rolling, even if its against your better judgment.
5) When forming a chapter, write out a bunch of code and examples first. When you think you have a cohesive set, sit down and write as if you're explaining the code you wrote to a friend or co-worker. Make sure your examples can flow together nicely, where possible. I found this approach to work well with RBP. If I couldn't come up with a great set of examples that went well together, I went back to the drawing board without ever writing a line of prose.
6) Ignore all of the above, and find a flow that works for you.
This stuff is hard, it's okay for it to be hard, and really, all you need to keep in mind is pretty much every other published author has been through the same hell that you'll find yourself in.
But you get a big reward in the end. You (eventually) get your sanity back.
Re: Ruby Best Practices (full book available for download)
#50Earlier quoted context omitted.
With the hash args the order could vary so I had to keep looking up what the possible argument key values could be. You can set slots on objects in any order that you want to: Foo.new.set_x(x).set_z(z) ...
Can you recommend an Io book for me? I want to hunt down the author and try to encourage them to make their code more Rubyish. Because you know, that's helpful.
I did recommend to the Io author that he create a Hash literal syntax because I like the fact that Ruby has one ;-)
To be clear, I think that it is great that you created this book. I just responded as I did because I'm often frustrated when I use Ruby APIs that sacrifice good design (imo) for syntactic terseness.