Updates projects with new ones

[rbdr/r.bdr.sh] / jekyll / _posts / 2015-09-05-api-notation.md

diff --git a/jekyll/_posts/2015-09-05-api-notation.md b/jekyll/_posts/2015-09-05-api-notation.md
index e482bb5ef81163aab6eb9f1f87b490ce4695fb23..8e62abc3403d00c829e78b5d8b9677ebfa5cbf31 100644 (file)
--- a/jekyll/_posts/2015-09-05-api-notation.md
+++ b/jekyll/_posts/2015-09-05-api-notation.md
@@ -5,7 +5,7 @@ tags: english specs
 color: purple
 header_image: api-notation.gif
 description: "API notation is a simple way to document the public
 color: purple
 header_image: api-notation.gif
 description: "API notation is a simple way to document the public

-contract of your componentsA"
+contract of your components"

 ---
 
 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.
 ---
 
 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.