Code that talks only to itself is not useful to anyone. Code that enables other code magnifies its power 10-fold.
But how do we enable other code, and those who write it? What makes a module extensible? What is that vague extra something that turns merely extensible code into an API, a library, and a cornerstone of other systems? How do we harness that power for ourselves?
Let us examine the Aphorisms of Good API design, and the 8-Fold Path of API Nirvana.
This session goes beyond how to write modules well to cover the question of how to write modules that spawn other modules and innovation by Coding for the Future.
Video at archive.org.
Module developers who want to write not just good code but code other developers will want to use.
Site builders and evaluators who want to know how to tell if a module is "doing it the right way".
Site Architects who want to know what modules are likely to be extensible in the future rather than evolutionary dead ends.
Comments
empty minutes
Hey Crell,
there are some empty minutes at the beginning of the video. Maybe you want to re-upload?