'. '

1stPublicReview

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (07:47, 3 September 2008) (edit) (undo)
 
Line 3: Line 3:
Now on to the critical comments. Yes, I know the first part of the book, the theory, maybe seen as something delaying the real pleasure - the practical code samples. In [[Have_You_Ever_Wondered|some sense it does]], however I just felt that given the wide audience of readers (just to quote the reviewer ''this book is really much more for anyone who writes code that anyone else consumes - and who doesn’t do that? This book is for any developer who is not brand new to software development''), I felt the need to get everyone on the speed, clean up the terminology, make sure we understand each other. Maybe I was too careful, as [[RichUnger]] said: ''you do not need your readers to agree with you 100%, maybe 99% is enough''. Well, I targeted for the 100%, and as a result, the book may be seen ''slow'' for those who are already on the same boat. Still, it has a lot of ''meat'' even for such readers, I guess.
Now on to the critical comments. Yes, I know the first part of the book, the theory, maybe seen as something delaying the real pleasure - the practical code samples. In [[Have_You_Ever_Wondered|some sense it does]], however I just felt that given the wide audience of readers (just to quote the reviewer ''this book is really much more for anyone who writes code that anyone else consumes - and who doesn’t do that? This book is for any developer who is not brand new to software development''), I felt the need to get everyone on the speed, clean up the terminology, make sure we understand each other. Maybe I was too careful, as [[RichUnger]] said: ''you do not need your readers to agree with you 100%, maybe 99% is enough''. Well, I targeted for the 100%, and as a result, the book may be seen ''slow'' for those who are already on the same boat. Still, it has a lot of ''meat'' even for such readers, I guess.
-
The other interesting comment was about the subtitle: ''confessions''. The comment is very likely true. I have to admit, especially after the confession I made at the end of [[Ever_Changing_Targets|Chapter 4]], that I have never been to a confession. My understanding of that term is really vague. However, we needed the subtitle to stress, that the book is not opinion neutral, that it contains personal experiences, opinions, etc. When [[ThanksEveryone#Clay_Andres|Clay]] suggested to use ''confessions'', I felt, yes, that is sort of what I am actually doing. Maybe this is not absolutely correct, but it helps set the right expectations up. At least I hope.
+
The other interesting comment was about the subtitle: ''confessions''. The comment is very likely true. I have to admit, especially after the confession I made at the end of [[Ever_Changing_Targets|Chapter 4]], that I have never been to a confession. My understanding of that term is really vague. However, we needed the subtitle to stress, that the book is not opinion neutral, that it contains personal experiences, ideas, stories, etc. When [[ThanksEveryone#Clay_Andres|Clay]] suggested to use ''confessions'', I felt, yes, that is sort of what I am actually doing. Maybe this is not absolutely correct, but it helps set the right expectations up. At least I hope.
I really like Mike saying: ''After reading many chapters, I went right to my open source project, [http://code.google.com/p/architecturerules/ Architecture Rules], and either changed code or emailed developer mailing list to suggest changes to code to encourage a better, more malleable and extensible API.'' Yes, this is it! This is the reason why I wrote [[TheAPIBook]]. Software for 21st century needs to be modular, needs to be well evolved and I am glad that [[TheAPIBook|my book]] can contribute to that.
I really like Mike saying: ''After reading many chapters, I went right to my open source project, [http://code.google.com/p/architecturerules/ Architecture Rules], and either changed code or emailed developer mailing list to suggest changes to code to encourage a better, more malleable and extensible API.'' Yes, this is it! This is the reason why I wrote [[TheAPIBook]]. Software for 21st century needs to be modular, needs to be well evolved and I am glad that [[TheAPIBook|my book]] can contribute to that.
Thanks for such nice review and I am eagerly waiting to see more. Btw. if you ever feel you have a note to share about API Design, feel free to jump on the [[Main_Page|apidesign.org]] wiki.
Thanks for such nice review and I am eagerly waiting to see more. Btw. if you ever feel you have a note to share about API Design, feel free to jump on the [[Main_Page|apidesign.org]] wiki.

Current revision

There is a review of TheAPIBook! Geertjan had just sent me a link to the first public review of the TheAPIBook. I was a bit nervous to open the page. I was not sure whether to get ready for absolute criticism or words expressing usefulness of TheAPIBook. I guess that a review which says this is without a doubt a book that you need to put on your bookshelf. This is the first book of its kind and the tips and tricks that it provides is timeless - a key attribute of any pragmatic software development book can only be seen in positive light. Thanks for the nice review, Mike.

Now on to the critical comments. Yes, I know the first part of the book, the theory, maybe seen as something delaying the real pleasure - the practical code samples. In some sense it does, however I just felt that given the wide audience of readers (just to quote the reviewer this book is really much more for anyone who writes code that anyone else consumes - and who doesn’t do that? This book is for any developer who is not brand new to software development), I felt the need to get everyone on the speed, clean up the terminology, make sure we understand each other. Maybe I was too careful, as RichUnger said: you do not need your readers to agree with you 100%, maybe 99% is enough. Well, I targeted for the 100%, and as a result, the book may be seen slow for those who are already on the same boat. Still, it has a lot of meat even for such readers, I guess.

The other interesting comment was about the subtitle: confessions. The comment is very likely true. I have to admit, especially after the confession I made at the end of Chapter 4, that I have never been to a confession. My understanding of that term is really vague. However, we needed the subtitle to stress, that the book is not opinion neutral, that it contains personal experiences, ideas, stories, etc. When Clay suggested to use confessions, I felt, yes, that is sort of what I am actually doing. Maybe this is not absolutely correct, but it helps set the right expectations up. At least I hope.

I really like Mike saying: After reading many chapters, I went right to my open source project, Architecture Rules, and either changed code or emailed developer mailing list to suggest changes to code to encourage a better, more malleable and extensible API. Yes, this is it! This is the reason why I wrote TheAPIBook. Software for 21st century needs to be modular, needs to be well evolved and I am glad that my book can contribute to that.

Thanks for such nice review and I am eagerly waiting to see more. Btw. if you ever feel you have a note to share about API Design, feel free to jump on the apidesign.org wiki.

Personal tools
buy