99 Bottles of OOP
sandimetz.com
sandimetz.com
"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."
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.
I will never understand programmer's cost/benefit analysis..
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.
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.
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.
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.
1: http://www.informit.com/store/practical-object-oriented-desi...
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.
-- 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.
Edit: looks like the later. The Products page has a description of both: http://www.sandimetz.com/products/
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 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).
Although, I should probably get around to reading Refactoring, and Design Patterns. I've heard those are good...
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.
Some of the other stuff I mentioned CAN work and be useful, though.
My point is that often adopting patterns/tools/conventions from other languages results in cruft like that.
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.
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.
Reasonable people may disagree.
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.
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.
I doubt Ruby OOP code would avoid using all metaprogramming, at the very least attr_accessor!
Unless you're doing configuration, Ruby syntax is as simple as it gets.
Might be worth reconsidering,FWIW.
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.
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.
The information is plainly stated in a way which is so simple it's novel.
That said, the broke college student in me is writing a postcard.