I love Sandi's writing - and how they're giving it away for people who can't afford it:
"Of course we want you to buy it. It's been years of our lives in the making, and we have bills too. However, if you absolutely cannot afford it, we'll make you a deal. Snail-mail us a postcard, and we'll email you a free copy.
A proper postcard, mind you, with a vacation-like scene, and an actual postcard stamp. Hand-drawn postcards are both acceptable and encouraged. The more effort you expend, the better we'll feel about our end of this bargain."
Like another commenter I think $49 is a bit high for a digital book. However, now that I know that they are giving it away for people who can't afford it I don't mind as much. I can afford $49 for this book even if I think it's a little high.
I guess this begs the question: if they dropped the price to $25 would more people be able to afford it and then they wouldn't have to give any away? I wonder what the "correct" balance is there.
That's assuming that what's in this book is exceptional (which you can't tell without a preview). I didn't think that Practical Object-Oriented Ruby was incredible, though it is a well-written tutorial of basic OO techniques. You could spend less than $49 on a couple good used copies of OO classics, or many more if you visit the right used bookstore. And it's not even a hard copy so it is competing with the wealth of good free information online about OOP. I might pay $99 for a hard copy of this, but no way I'd pay $49 for a PDF.
> I might pay $99 for a hard copy of this, but no way I'd pay $49 for a PDF.
Generally, I like physical books more than electronic ones, and I'd be willing to pay a premium for it. From what you're saying, a PDF of the book would provide you < $49 of benefit, while a hard copy would provide you > $99. In your opinion, what is the difference in value between those? What I mean is, what specifically about the hard copy provides enough benefit that you'd pay over twice as much for it?
IMO, the greatest proportion of value for a book I'd actually buy is in the information it contains and the presentation of that information, rather than the form it's published in. It's not like I don't have several devices that I could use as portable readers, after all.
I have to say it largely depends on the location. I have moved progressively to more and more affluent countries (now in my fourth, the US), and it had radically changed how I view "value", especially money. A good book (and I like Sandy's work) will easily pay for itself now that I can actually afford to buy it and 50 dollars is not such an immediate hit on my bank. Before, 50 dollars is a blood rush. :D
I don't have a problem with the price dude. Calm down. The main reason why I said that I think it is a little high is that I've already paid for POODR and have listened to countless talks from Sandi.
Is it just me, or does $49 seem high for a digital copy? I went to buy it expecting it be somewhere around $20, and then had a bit of sticker shock when I was in the checkout path. I know it took a lot of time and effort and on the author's part, so not saying it isn't worth it, but for a non-physical copy it seems like a pretty steep price. I ended up passing, wonder how many others did the same as me.
It's high, but not terribly high, imo. When it comes to professional development, this could be considered quite cheap. A freelancer who charges $100/hr can pay for this in 30 minutes, and if it gives more than 30 minutes of productivity in the future, then it was worth it. (Figure out your rates, and do the math. Odds are that it'll be worth it.) Furthermore, a lot (if not most) companies will be willing to purchase such a book for their employees, because the math is even better for them.
If you're a tech writer like Sandi, you can absolutely get away with $49/copy, or even $99 or $199 per copy. They usually offer extended examples online or what-have-you to justify the $199 price, but it happens all the time.
For professional development books like this, you can't really think of it in the same terms as leisure books, like fiction, where the only benefit is having a good time. There's a benefit that goes beyond entertainment -- benefits that are monetize-able by the reader. If I read this book, and I learn something that allows me to do something in 30 minutes that previously took me an hour, then I've effectively doubled productivity. That means I'm more valuable -- and therefore, the book is more valuable. More valuable = more expensive.
Hope that helps explain why it's the price it is. That said, I'm passing too. I tend to prefer physical books for professional development, or ideally, a physical + digital combo.
I just wish there was a sample chapter or something. This sounds extremely interesting and useful, but I'm not willing to shell out close to $50 whether it is interesting and useful. I'm also not going to send a postcard because I can afford it, I'm just not willing to risk $50 on something I have so little information on. If we were in a bookstore I could at least crack it open and see what it looks like inside.
Edit: Ah, found sample pages and chapter 3 at the purchase site[1]. That would be a really good link to put in this announcement.
You are correct. I arrived there by clicking on the bottle diagram, and wasn't paying attention to the specific book it brought me to as I assumed it was the one the page is about and was excited to see a link to sample content. That's a shame.
The value of a book is not in its format (digital vs. print), but in the quality of the content and the reputation and relationships the authors have earned due to their previous efforts. And you can always try negotiating a discount via postcard ;-) http://www.sandimetz.com/99bottles/postcard
For me as a consumer, the format is very much correlated with price. I am always willing to spend more money for a physical copy of a book than the digital version. For them as publishers, it also costs less to come to market with a digital versions, and so should be reflected in the price. I do hear what your saying about value being derived from content, but without a free preview of a couple chapters and a price that I deemed to high, I ended up passing.
If I don't think about it, yes, a physical version seems to be worth more, because I feel like I'm actually buying a "thing", rather than just paying for access to information. It feels nicer to know that printing it cost the publisher more to produce; there's a sense of fairness. It's an interesting psychological effect.
And the same can be said about the digital version. You can use it in ways that you can't use a physical one. Which is better is completely a matter of preference, IMO.
Physical: It's pleasant, intuitive, and the tactile aspects change as you go through the book. Page layout and the feel of flipping through the book can be nice mnemonic devices.
Digital: I can carry a few thousand books on my pocket, put copies on all my devices, do full text searches, follow hyperlinks in the document, etc.
As stated the book is not finished yet, two chapters are missing, so they can't print a not finished book:
-- Please Note --
99 Bottles of OOP is currently available in digital form only.
This is version 0.2 beta-1, which contains about 45,000 words / 240 pages. Although it qualifies as a complete book as it stands, two chapters are pending. When they are finalized, we'll automatically email you a link to the updated book.
My book (Haskell Programming FFP) is $59 for the ebook version, but it's a lot longer and covers a lot more, because of the "from first principles" part and the method we use.
We heavily discount it or give it away for students and others who can't afford it. We don't ask for a postcard, just an email describing their situation.
Makes sense. Most of our book is word of mouth. People know what they're getting and what we cover, we're pretty detailed about it: http://haskellbook.com/progress.html
Sandi Metz has another book on what I would guess is a similar topic, Practical Object-Oriented Design in Ruby (colloquially, POODR). I found that book to be highly practical to daily development and I expect this to be no different. You might try googling for info about that book or perhaps try the mailing list if you want to find out more before buying.
This is designed for people who just pull out their credit cards and buy the book. I would expect she and Katrina have a significant number of those folks. No preview needed.
I bought this and regretted it. The writing is nice and friendly, giving clear explanations. They are particularly good at pinpointing and naming problems with design.
However, contrary to the expectations I had from the web page, here, and the introduction, it offers little to anyone with experience. I learned almost nothing I didn't know from a few articles about TDD (I don't practice it) and exposition is slow (no different from most programming books). The chapters currently available also have little to do with the OO part of OOP: several "OOP terms" are mentioned and used, but they apply and are applied without the context of multiple classes.
I also agree with others about the high price. This seems a lot to me for an ebook, and having got through it very quickly the feeling is only confirmed. Two more chapters are due, as it's a beta, but I doubt this will change my view.
I feel it would be a good book for someone new to programming and potentially someone new to TDD. I would still feel obliged to mention value for money to such a person.
I think it would be helpful to have a sample chapter.
I haven't read an OOP book in awhile, but when I did they often had a lot of examples that while reasonably easy to follow didn't actually translate into real world usage (`Car extends Vehicle implements Drivable` or whatever).
I might be picking this up. Most OOP design books I avoid, as I have little money and I dislike code with Java Syndrome (heavy focus on inheritence and hierarchy, extreme verbosity, IDE focus, boilerplate with no end in sight, patterns to replace your favorite features from Lisp, java.net.org.lang.lang.really.long.reallylong.import.paths.path, IteratorStrategyProviderFactoryFactoryFactory, etc. yes, I'm exaggerating quite a bit, but there's a reason I avoid Java like the plague), but Ruby tends to play home to practicality, and smalltalk refugees. This is good, and means that this book is a far safer bet than, say, flashy OO design book of the week.
Although, I should probably get around to reading Refactoring, and Design Patterns. I've heard those are good...
You might find that most of the Design Patterns and even some of the Refactoring book are focused on working around limitations in Java/C++-style languages.
>Although, I should probably get around to reading Refactoring, and Design Patterns
I'd been programming for 20 years before reading either.
Both were...entirely unsurprising. Design Patterns at least defined a useful vocabulary for talking about different patterns, so I found it useful in that respect, and at least some of the patterns are useful outside of a Java/C++ language. Refactoring had some good wisdom on OO design, but it was pretty much all stuff I'd picked up elsewhere or come up with on my own.
Wouldn't hurt to read through both at least once to see if there are any surprises for you. Might be safe to just check them out of the library, though. I kept Design Patterns around but gave away my Refactoring copy.
Personally I really liked "Head First: Design Patterns" because it's more about the overarching strategies (e.g. composition vs. inheritance) which design patterns are merely examples of. It was more of a top-down approach - I didn't realize memorize the patterns themselves, but internalized the justifications for them.
Seeing as I have the freedom to code in lisp, etc., much of Design Patterns may be of questionable value. However, knowing my own weaknesses writing code (every piece of code I have written is terrible), and my relative newness to programming (I've been doing this on and off for 7 years, but rarely seriously), Refactoring seems like it may be of value.
heavy focus on inheritence and hierarchy, extreme verbosity, IDE focus, boilerplate with no end in sight, patterns to replace your favorite features from Lisp, java.net.org.lang.lang.really.long.reallylong.import.paths.path, IteratorStrategyProviderFactoryFactoryFactory, etc.
What people need to get their heads around is that everything is about cost/benefit in particular languages in particular contexts/environments. What is the "density of reward" in the edit/test/debug cycle? What is the density of punishments? What comprises the cognitive load and where does it come from? Just because something is good for one thing, doesn't mean it's good for another.
Well, yeah, but lighening up on the boilerplate and shortening your import path a bit never hurt anybody. 50 copy-pasted lines don't make your app more flexable.
Some of the other stuff I mentioned CAN work and be useful, though.
Yes, but you seem to be arguing that that cruft is good.
Arrgh, NO! I'm saying cruft is bad! You're taking something that's good in one context, then naively trying to use it in a different one, mistakenly thinking it will have the same goodness. Analogous errors: taking a crop from one environment, then expecting it to grow well in a different one. Doesn't always work. A clever saying from one social context might bomb in another.
Oh. Sorry. You misread my comment. Yes, I know what it says, and in retrospect, I should have been clearer.
After doing a bit of simple Java programming for a bit, I thought it was okay, if a bit verbose. A while later I looked into how to start with Android development, which is what I really wanted to get into. I had seen some of the hate spewed at java, and had been having some frustrations with it myself, and was starting to feel a little unsure about the language. Little did I know...
The first few lines of the Android tutorial were, "copy-paste about 20-30 lines of code, and then type a few more. This should get you a button in the middle of the screen that says "hello world."
This is the moment when I gave up on Java. Because that wasn't me, tossing my warped ideas, taken from other languages at the thing. These were professionals, who wrote an API, and clearly thought that this level of boilerplate was acceptable, nay, necessary.
If it takes 20+ lines to instatiate a simple component, and have it say, "hello world," than how do you write applications in this thing? In JS, I could've been done in less than 5 lines (android uses an interface builder, so the comparison isn't unqualified). In TCL, this is maybe two lines. In C, maybe the program would have been comparable, but in C, you have to malloc and instantiate objects that the library and runtime take care of for you in java. There is no excuse.
The fact that Java didn't have lambdas, still lacks many common features from higher level languages, and locks you an an OO straitjacket is irritating for me sometimes, but understandable. The verbosity, on the otherhand, is unneccessary, unusable, and unacceptable.
The intro sold the book to me but I'm a bit reluctant to buy it because of the fact that it uses Ruby. I've just started working with Java (straight from University last year) and I've come to realise that in comparison to other OO languages which have evolved their syntax (C# & Python) Java hasn't. I doubt it'll help me with Java. I've already invested in a few books and test engines, mainly for my Oracle certifications.
I took a class with Sandi, where this material was covered. I paired with one developer who did mostly Java and he seemed to get a lot of the class even though he hadn't really programmed in Ruby.
I found "Practical Object-Oriented Design in Ruby" to be immensely valuable, even though I don't really use Ruby much. I imagine it's the same for this book.
The best thing you can do to master the Java-only world is to peek outside of it. (And that is true for almost every X-only world, whatever the X value.)
After touching most mainstream languages, I conclude that many of the languages have different syntax and stuff, but the principles are mostly the same. So without having read this book, if it teaches you OOP via ruby, you should be able to apply it in Java as well, but maybe with different syntax but the outcome would be the same
If you're planning a career as Java developer, I highly recommend this book. Sandi is a great writer and Ruby is just a tool to communicate a message. You'll gain a lot of insight about how to write great Java by reading any of her books or articles.
I can only think of module mixins. Everything else (blocks, anonymous functions, syntax sugar) can be roughly approximated (i.e. generics), since I strongly doubt the book would use any of the metaprogramming features.
Having taken Sandi's in-person course (which sounds like it covers a lot of the same territory as this book), the vast majority of it would be perfectly applicable to Javascript. Ruby lets you get away with some neat tricks, like dynamically loading classes by name to avoid ugly switch statements, or the occasional bit of monkey patching, but it's not the focus at all and it's easy to see how you could accomplish it in a more "traditional" way.
The book seemed rather short for the price. Definitely had useful information that helped me to understand issues I have with code design. It wasn't worth $50 to me, but may be for other people.
It seemed expensive but I bought it anyhow because any small insight into programming or process could easily be worth $50 over time.
It's worth noting that the book is incomplete, chapters 5 & 6 are still being written. If I'm able to complete the book in the next day or so I'll post a follow-up.
Sandi really distills knowledge well. I haven't bought this book yet, but after reading POODR, I'd take 20 pages from her over 100 from another author. I think it's easily worth $50, but I realize we're in an age where we're used to $19 ebooks. Again, I'd pay $100 for her material over somebody else's $19 book. (Not compensated or anything, just a fan of not wasting my time and of awesome materials that help me accomplish that goal)
$49 seems pricy for a digital book, but like said before, it's a small price to pay in the grand scheme of things if you're making a decent salary and if you write much better code after reading it.
That said, the broke college student in me is writing a postcard.
Dammit, the epub format is such a disgrace for books, especially for those containing code snippets. I've yet to encounter a book that doesn't suffer from being published as epub. I prefer a well formatted pdf that just looks like the printed book, any time.
Does anyone know how ruby specific this gets? Is it more about general software development while simply using ruby as the vehicle or is it something only ruby specialists would get something from?
Sandi came and did the training this book is based on with our company, and the iOS/Android devs got a lot out of besides the Ruby peoples... it uses Ruby, but it's not about Ruby.
"Of course we want you to buy it. It's been years of our lives in the making, and we have bills too. However, if you absolutely cannot afford it, we'll make you a deal. Snail-mail us a postcard, and we'll email you a free copy.
A proper postcard, mind you, with a vacation-like scene, and an actual postcard stamp. Hand-drawn postcards are both acceptable and encouraged. The more effort you expend, the better we'll feel about our end of this bargain."