APIDesign - Blogs

First Public Review of Practical API Design Book

JaroslavTulach — Tue, 02 Sep 2008 19:42:00 GMT

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.

--JaroslavTulach 19:42, 2 September 2008 (UTC)

Joel Neely on Enums in APIs

JaroslavTulach — Tue, 26 Aug 2008 21:22:00 GMT

Today I found out that there is an interesting comment to the blog entry published by Andrei a week ago. Andrei shared with us few thoughts on the use of enums in API. Joel Neely noted that it all depends on how the enum is used in the API. I cannot do anything else than agree with his words, yes it depends on whether the enum is used covariantly or contravariantly. If the enum is used covariantly only, then extending it with new constant in new version of the API is OK.

The only problem is that as soon as you publish an enum, one can immediately write a switch statement over it. And the switch statement's behaviour is contravariant. That is no good news for the API writers and compatible extensibility of their enum based APIs...

--JaroslavTulach 21:22, 26 August 2008 (UTC)

Are there any Languages Ready for API Evolution?

JaroslavTulach — Sun, 24 Aug 2008 06:50:00 GMT

When I was describing my API design adventures in TheAPIBook, I could not realize that many of these problems would not even appear if we had better languages, or systems more suitable for the DistributedDevelopment.

I may be wrong, but I do not know about any language that would support modularity. And here I mean not compilation piece by piece, but also modularity in time. Because that is the kind of modularity that is needed quite often during development of APIs for our libraries.

At one point of time we release a version of a library and distribute it to others by publishing it on the website. Now people unknown to us, distributed all around the world download it and use it. As a result, the amount of applications built on top of such library is increasing, which implies also that the amount of bugs and feature requests is growing too. After a while the time to release new version of the library comes. However what if the first version used to have a class:

public abstract class View {
  public abstract String getDisplayName();
}

What if one of the feature requests demands to add an HTML title to each view. Can we change the view class to following form:

public abstract class View {
  public abstract String getDisplayName();
  public abstract String getHTMLTitle();
}

Indeed, this cannot be done. Existing subclasses of View would no longer compile, because the change is not source compatible. Also, even if someone links already compiled subclass with the new version of the library, the Java virtual machine will complain and throw some kind of linkage error, as definition of an abstract super class method is missing.

I would love to see a language or system that would fail the compilation whenever I want to modify my already released classes in a style that could prevent some of their users to continue to use them in previously working way. This would be the real modularity, which is ready for changes in time. So far it seems to me that the current languages do not deal with changes in time really well. Just like Andrei described in his Enums in APIs blog, it seems that our languages do not think about the process of API evolution much and include constructs that one needs to avoid to make DistributedDevelopment possible.

Releasing new version of libraries with modified APIs is really common and our software engineering practices cannot live without it, yet it seems that there is no language in the world that would make this easy and clueless. Or am I wrong?

Also lively discussed at Lambda the Ultimate.

--JaroslavTulach 06:50, 24 August 2008 (UTC)

Have You Ever Wondered?

JaroslavTulach — Sun, 17 Aug 2008 20:42:00 GMT

Many people want to know, before they start to read a book, whether it can help them solve some problems they have faced. That is very likely reason why many books start with have you ever wondered sections. The Practical API Design book does not contain such section itself, however that in no way means that there it is not helping to solve problems! You can bet that there is a lot of useful advices! The book is a lab journal describing adventures of NetBeans project and as such, it is almost completely stuffed with problem solutions. Here is short online version of Have You Ever Wondered to demonstrate that. Visit the page and check yourself what problems can TheAPIBook solve for you!

--JaroslavTulach 20:42, 17 August 2008 (UTC)

Win the Practical API Design Book

JaroslavTulach — Thu, 14 Aug 2008 16:11:00 GMT

As part of Chapter 1, The Art of Building Modern Software I wanted to demonstrate that the need for programmers is really big and that almost everyone who wants to get a job as a programmer may get it. For this I wanted to reuse a picture of a San Francisco homeless that is famous for wearing sign with "Will Code HTML for Food". However I could not do that, because the picture is of really low quality. That is why I needed a new re-take. We already have some, but still, I'd like us to start sharing! As sharing of pictures is sometimes easier than sharing of API Design ideas, please participate in a photo contest! Get a chance to win TheAPIBook by taking "Will Code HTML for Food" like picture and adding a reference to it to HtmlForFood by Aug 28, 2008!

I am looking forward your submissions.

--JaroslavTulach 16:11, 14 August 2008 (UTC)

Visual Aspects of an API

JaroslavTulach — Mon, 11 Aug 2008 11:40:00 GMT

The usual consensus is that visual aspects that are presented just to the end user are not part of API of some application. This is usually well justified and correct, except in some situations...

--JaroslavTulach 11:40, 11 August 2008 (UTC)

New LaF of apidesign.org

JaroslavTulach — Mon, 04 Aug 2008 10:16:00 GMT

There was a lot of factors that influenced me last year, when I was searching for publisher of my book. However one of them must have been slickness of cover. I really like the black and yellow style of Apress books. I like it so much that I decided to make it the default Look and Feel of the apidesign.org website.

I'd started with MonoBook theme and modified it to be a bit darker. I do not code CSS for living, but CSS file editing support in NetBeans IDE is good, so it was quite entertaining experience. I am sure not everything is perfect, but I'll keep fixing problems as they appear. If you notice something ugly or broken, let me know.

--JaroslavTulach 10:16, 4 August 2008 (UTC) --JaroslavTulach 10:09, 4 August 2008 (UTC)

There is a Reason Why Every Book is Dedicated to Family

JaroslavTulach — Sun, 27 Jul 2008 19:00:00 GMT

I've heard this sentence at the J1 this year and I cannot get it out of my mind. Yes, family plays a really big role in the life of a writer. So please let me thank to it as well to other friends.

--JaroslavTulach 19:00, 27 July 2008 (UTC)

Good Book Needs Good Reviewers

JaroslavTulach — Fri, 18 Jul 2008 19:44:00 GMT

It is time to thank to all my reviewers as today I've found out that you can order my book on Amazon.com. Please look at my little ThanksReviewers to find out why to order my book. I believe that all reviewers really shape it to something worth reading. Thanks a lot.

--JaroslavTulach 19:44, 18 July 2008 (UTC)

Removing Fear of Writing Documentation

JaroslavTulach — Thu, 17 Jul 2008 16:05:00 GMT

Heuréka! As I've just noted in a dedicated page describing chapter 16, Teamwork one GeertjanWielenga's fear has just been overcome!

--JaroslavTulach 16:05, 17 July 2008 (UTC)

Enums in APIs

AndreiBadea — Wed, 16 Jul 2008 14:18:00 GMT

An user of an enum might want to ensure he has processed all its fields. This can be problematic when the user doesn't own the enum, such as in an API.

--AndreiBadea 14:18, 16 July 2008 (UTC)

Question on classes and interfaces

JesseGlick — Tue, 15 Jul 2008 09:33:00 GMT

Someone asked: I guess that, roughly, a client API should use abstract classes while a support/provider API should use interfaces?

To which I responded...

--JesseGlick 09:33, 15 July 2008 (UTC)

Dependencies Are Important Type of API

JaroslavTulach — Tue, 15 Jul 2008 07:05:00 GMT

New type of API has been discovered!

JaroslavTulach 07:05, 15 July 2008 (UTC)

Adventures with PHP and MediaWiki

JaroslavTulach — Sun, 06 Jul 2008 21:14:00 GMT

During the last week, I was slightly playing with various enhancements to the content of the API Design wiki.

--JaroslavTulach 21:14, 6 July 2008 (UTC)

Request/Response Pattern Revisited

JaroslavTulach — Wed, 25 Jun 2008 21:02:00 GMT

Here is few additional thoughts about Request/Response which did not make it into TheAPIBook's explanation of Request/Response pattern.

--JaroslavTulach 21:02, 25 June 2008 (UTC)

Book is never Written by a Single Person

JaroslavTulach — Mon, 23 Jun 2008 12:01:00 GMT

The Practical API Design book has been sent for print over the last weekend. I take it as a good opportunity to say thanks to all the people who helped me write it. The first set of ThanksEveryone notes is now available and covers those who "manually" contributed. I still need to thank to all those support "units" around me - something left for next blog entry...

--JaroslavTulach 12:01, 23 June 2008 (UTC)

Entering the Blogosphere

JaroslavTulach — Sun, 15 Jun 2008 09:33:00 GMT

I have created my blog, does it mean that I finally exist?

--JaroslavTulach 09:33, 15 June 2008 (UTC)