1. Hello everyone,

    I just wanted to know if the second edition of the book is going to be published in July 2009.

    Reason for asking: I've seen a pre-order site and was wondering if it's correct.

    http://www.borders.com/online/store/TitleDetail?sku=0470481285

    Thank you. 

  2. Hello everyone,

    I just wanted to know if the second edition of the book is going to be published in July 2009.

    Reason for asking: I've seen a pre-order site and was wondering if it's correct.

    http://www.borders.com/online/store/TitleDetail?sku=0470481285

    Thank you. 

  3. We have been in talks with the publisher regarding a second edition and late last week we received the green light on it.  I don't know of any specific publication date or schedule at the moment, so the date may shift one way or the other.  There's quite a bit of content to update and edit so it will take some time before we're even done generating content to enter the production pipeline.

  4. Any chance that the chapter dedicated to Addon Studio might be replaced with a more useful chapter on Ace-based addon development? And if not replace, then add some Ace coverage?

    The reason I ask is the existing Ace how-tos are really lean, a lot of the APIs are undocuments, or documented poorly, and because the Ace framework is so darned popular!

    I am not asking for a chapter or two covering everything Ace, like all the libs, but just something more involved than the "Hello World" addon that really doesn't teach much. Afterall, I daresay Ace probably needs a whole book unto itself.

    Hey, there's an idea... .too bad I don't know enough to write it!

  5. Any chance that the chapter dedicated to Addon Studio might be replaced with a more useful chapter on Ace-based addon development? And if not replace, then add some Ace coverage?

    Absolutely not.  I firmly and 100% believe that his is not how people should be learning to write addons.  The Addon Studio chapter didn't push anything else out of the book, it was added at the last minute by a contributing author to introduce the program.  The chapter is being rewritten for the second edition.

    The reason I ask is the existing Ace how-tos are really lean, a lot of the APIs are undocuments, or documented poorly, and because the Ace framework is so darned popular!

    Popularity is not an indicator of quality, ease of use, or anything other than the fact that people write addon using it.  The fact that their APIs are undocumented is one of many reasons why we won't be writing any Ace HOWTO in this book.

    I am not asking for a chapter or two covering everything Ace, like all the libs, but just something more involved than the "Hello World" addon that really doesn't teach much. Afterall, I daresay Ace probably needs a whole book unto itself.

    Ace doesn't need a book.. because the book we've already written teaches you how to do everything anyway.  Hiding behind a layer of abstraction in this case just guards you from having to understand what is actually happening in the client which is a terrible thing.

    I'm sorry if I'm coming across as rather harsh.. but the book already teaches you how to write addons.. I don't understand what Ace adds in any way other than bloat to addons that don't need to be using it.

  6. Perhaps I should clarify my position.  I don't have anything wrong with Ace (as a matter of fact the bulk of the code in AceDB is mine, and I was heavily involved in the direction and development of the Ace3 framework).  I also use other components in some of my addons.  That being said, it's about being lazy.  It's about hiding your eyes from the intricacies of the Blizzard API and having a layer of abstraction to work with instead.

    The problem with this is people's reliance on them.  Unlike the standard libraries for Microsoft Windows (which are included with every single distribution of the operating system) the Ace libraries are not included, but there are a large class of developers who never really learned what was going on behind the scenes because they started with an "Ace" tutorial and never learned anything behind it.  These people will continue to include components of Ace3 in all of their addons, even if they're 10 lines long!  The loading, maintenance and setup of using libraries in addons is an advanced topic that will be covered in the book (and yes, I will likely address some of the more useful ones in particular).  This isn't an "Ace" problem.. but the promotion of libraries like this would help to make the problem worse.

    However, I know for a fact that anything that you want to use a library for, you are perfectly capable of writing so long as you understand the algorithm or process.  That understanding is way more important to me than teaching someone how to use a library in order to be a bit "lazier".  I'm all for ease of development and ease of use, but not at the expense of understanding.

    That and I refuse to promote Ace3 in particular when there are other libraries and frameworks out there that work just as well or better.  It's not a fair assessment of the community to bias the coverage in such a heavy way "just because it's so damn popular".  That's not a good enough reason for me.

    Hope that makes sense.

  7. It does make sense, and that's why I bought your book in the first place. I knew just enough at the time I bought it to realize that the importance of fundamentals can never be overstated.

    I'm sorry to have provoked you about Ace; that wasn't my intent. In all actuality, I am very proud my first addon is written entirely using the Blizzard APIs, widgets, and Events – I wouldn't have it any other way.

    Don't mind my first post, I was just musing some musings, and if there is no coverage of extra-curricular frameworks in the second edition, I'm very alright with that.

    I do agree with you, as some people have taken the Ace'd "Hello World" kind of thing too far; if something can easily and quickly be done with the tools Blizzard has provided, I say go get it done.

    Hmm, I seem to be defending Ace, and I'm not. At least, not trying to. No, I bought your book for the very reasons you and your co-authors wrote it: it teaches basics, fundamentals, and encourages the reader to lay solid groundwork. I would never have been able to modify SmartRes, or write MrBigglesworthDeath without your book, and I am eternally grateful. It took me four years, but here I am, thanks in no small part to all of you.

    Thank you. Again.

  8. It does make sense, and that's why I bought your book in the first place. I knew just enough at the time I bought it to realize that the importance of fundamentals can never be overstated.

    I'm sorry to have provoked you about Ace; that wasn't my intent. In all actuality, I am very proud my first addon is written entirely using the Blizzard APIs, widgets, and Events – I wouldn't have it any other way.

    Don't mind my first post, I was just musing some musings, and if there is no coverage of extra-curricular frameworks in the second edition, I'm very alright with that.

    I do agree with you, as some people have taken the Ace'd "Hello World" kind of thing too far; if something can easily and quickly be done with the tools Blizzard has provided, I say go get it done.

    Hmm, I seem to be defending Ace, and I'm not. At least, not trying to. No, I bought your book for the very reasons you and your co-authors wrote it: it teaches basics, fundamentals, and encourages the reader to lay solid groundwork. I would never have been able to modify SmartRes, or write MrBigglesworthDeath without your book, and I am eternally grateful. It took me four years, but here I am, thanks in no small part to all of you.

    Thank you. Again.

    It's really no big deal, I didn't feel you were antagonizing, I just wanted to make it very clear why I made the decisions I did when writing the book =)

  9. There are times when adopting a "lazy" process actually helps.  I manage the Titan Panel project.  Titan Panel was raw -- completely in the beginning.  No library support and all BlizzardUI internals.  Then we wanted to clean it up and make it more efficient.  This required forcing plugin authors to adjust the way they hooked our timing procedures.  This brought about the inclusion of LibRock and the LibRockTimer specifically.  Once we cleaned up the code and made it quicker with less CPU load, we tackled another aspect of improvement and incorporated DataBroker functionality.  This lead us to the Ace3 framework.  AceTimer, AceHook, et al.  We cleaned things up even more making it leaner and quicker.  We just finished integrating AceLocale which will resolve our massive localization.lua issues since we're distributing with support for so many languages.

    The gist is that with Titan Panel being multiple megabytes in size with a significant level of complexity, the team was looking for something to make our lives easier -- hence Ace3.  So there are times when it's not necessarily a bad idea too add a little bit of "lazy".  It's about getting a handle on a rather complex addon and all it's individual parts.  True, the Ace3 documentation is sparse.  They need a really nice Wiki.  I also agree that people should not rely upon a library for all their processing needs.  You have to understand the core functionality of what is going on or you will not grasp the overall "big picture".

    Anyway, I own a copy of WoW Programming and I look forward to the second edition.  It's a valuable resource that cannot be understated and has an honored place on my computer desk right between the Perl "camel" book and the Backup and Recovery "gavial" book.