-When writing specifications and trying to figure out how components will interact, an important part is to define the public API as the contract others can depend on: So if you have a complex feature where several people are collaborating, you can ease up the integration woes by properly defining the contract they'll be using to communicate. This means that I usually end up having to write APIs in text files constantly, and over the years I've come up with a notation for this.
+When writing specifications and trying to figure out how components will interact, an important part of my workflow is to define the public API as the contract others can depend on: So if we have a complex feature where several people are collaborating, we can ease up the integration woes by properly defining the methods, properties and events they'll be using to communicate. This means that I usually end up having to write APIs in spec files constantly, and over the years I've been using and developing a notation for this.
git.r.bdr.sh / rbdr / r.bdr.sh / blobdiff